1. User Guide
  2. FAQs
  3. Validation and deployment
  4. Validation
  5. What checks are performed during validation?

What checks are performed during validation?

General validation checks

For a study to be deployed to Oracle InForm, it must pass a series of validation checks. For more information, see:

Validation area Must be true for successful validation
Study objects
  • All study object RefNames are valid and unique.
  • Reserved words are not used as RefNames.
  • References to study objects are valid (for example, if you delete an item from a form, you make sure that the layout does not continue to refer to the deleted item).
  • The study does not contain:
    • Duplicate references to a study object (for example, if you import an archived study that contains duplicate references).
    • References to study objects that are not included in the study.
    • Empty string resources.
  • A study object is not a child of itself.
  • Parent/child study object relationships are valid.
Locale and translation
  • At least one locale is selected in the Study Editor as a deployment target.
  • Translations to all study languages are complete.
  • Notes on sections are translated for all locales. If you provide a translation and then clear the value, the translation is considered valid.
Layout
  • The study contains form layout definitions for all deployable locales.
  • You have provided translations for captions and notes for all supported locales for the study.
  • An error has not occurred with any layouts.
Rules
  • Rules compile successfully, including rule templates and workflow rules, whether or not they are used.
  • Rules do not refer to study objects that have been deleted.
  • Rules reference the current RefNames of study objects. If a RefName is not updated automatically, you must manually update the RefName in the rule.
  • Only one current instance of a repeating form is referenced in a rule.
  • If the Current() method is used in the rule expression, the target of the rule action is a child of the study object referenced by the Current() method. In addition, validation considers the lowest level of Current() that you use. For example, for Visit1 and Form1:
    • The following expression is valid only if you apply the rule to a child study object of Visit1.

      this.Visit1.Current().Form1.I1 == 1

    • The following expression is valid only if you apply the rule to a child study object of Section1.

      this.Visit1.Current().Form1.Current().Section1.Current()I1 == 1

    • The following expression is valid only if you apply the rule to a child study object of Form1.

      this.Visit1.Current().Form1.Current().I1 == 1

      For more information, see the Rules Reference Guide.

Validation checks for Oracle InForm deployment

Validation area Must be true for successful deployment to the InForm application
Study The study has at least one study event.
Study design A warning occurs if the title or RefName of the study design, when appended with the version and locale of the study design, might exceed 63 characters. If the warning occurs, shorten the title or RefName, or the deployment process truncates the title or RefName in the Oracle InForm application.
Common visit For studies with common forms, if you translate a title or short title of the common visit for one language, the title and short title are translated for all languages.
Study event
  • Each study event has at least one form.
  • A study event is not used on both a study element and a study design.
Form
  • Each form:
    • Contains at least one item.
    • Has a layout defined for each locale that is deployed.
    • Does not contain duplicate items.
    • Is included in a study event no more than once.
  • Each Study Completion form has a Completion Status item.
  • Checks for form associations:
    • Associated forms in a repeating study event must have the same type; that is, both are repeating forms or repeating, common forms.
    • Forms in repeating study events can only be associated with forms in the same repeating study event.
    • A repeating, common form can be associated with more than one form if the forms are repeating, common forms in the same study event.
    • A form that is not repeating or common can only have one form association.
    • A warning occurs when associated forms are in different study events, and indicates that this functionality is available for Oracle InForm release 6.0.1 or later.
Section

For a regular section:

  • The section has a layout defined for each locale that is deployed.
  • If the section was deployed to a LIVE study, it is not changed to a dynamic grid section during an in-place revision or study version change.

For a dynamic grid section:

  • The source object is a repeating form or section.
  • The source visit referenced in the dynamic grid section appears in the study.
  • The source visit referenced in the dynamic grid section is included in the study design.
  • The source visit referenced in the dynamic grid section is not repeating.
  • The source form referenced in the dynamic grid section appears on the visit referenced in the dynamic grid.
  • The source form referenced in the dynamic grid section is not common.
  • The source section referenced in the dynamic grid section exists on the referenced source form.
  • The source section referenced in the dynamic grid section is not also a dynamic grid section.
  • The source items referenced in the dynamic grid section appear in the study.
  • The source items referenced in the dynamic grid section exist on the referenced source forms or sections.
  • The codelist subset selection for an item is the same on the source object as in the dynamic grid section; that is, for an item with an assigned codelist subset, you have not changed or removed the codelist subset assignment on the source form after mapping the item to the dynamic grid.
  • Either the source form or section referenced in the dynamic grid is repeating, but not both.
  • The dynamic grid section does not appear on a common form.
  • The dynamic grid section does not reference its own parent form.
  • If the dynamic grid section was deployed to a LIVE study, it is not changed to a different type of section during an in-place revision or study version change.
  • If the dynamic grid section was deployed to a LIVE study, its source visit, form, section, or item path is not changed during an in-place revision or study version change.
  • The dynamic grid section contains items.
Item
  • Questions for top-level items are not blank.
  • Year range for date time items is valid (for example, start year cannot be later than end year).
  • The precision value of a float item is not longer than the specified length of the item.
  • The nesting of compound and conditional items is not greater than five. If an item holds more than one child control, a group control is created, and each group control counts as one level of nesting.
  • Each compound item has at least one child item.
  • An item that is designated as a key item is not:
    • Formatted as a checkbox.
    • An item on which other items are conditional.
    • Conditional on another item if the key item is a child of a compound item.
  • The study does not contain any items for which NA or UNK is the RefName.
  • An item that is designated as Personal/Protected Health Information (PHI) is not included in the subject line or body of an email to be sent by a rule.
Codelist and codelist item
  • Each codelist has codelist items.
  • Each codelist item has a label for the appropriate locale.
  • Each codelist item has a label for the appropriate locale.
  • The codes of codelist items are unique within a codelist.
  • The codes for codelist items on text items do not exceed the length that is specified for the text item.
  • The codes for codelist items match the type of the codelist. For example, the codes for an integer codelist cannot contain letters.
  • The code of a codelist item that is conditional on another item has not been modified since the codelist item was made conditional.
  • Codelist labels do not contain apostrophes.
  • The Study Completion Status Item custom property is not set for codelist items in multiple items.
  • Each instance of a copied or linked codelist item has the same codelist type.
Codelist subset
  • Each codelist subset has one or more codelist items.
  • Each codelist item in a codelist subset exists under the parent codelist.
  • Each codelist subset exists under the item on which the codelist exists.
  • Codelist items used for conditional values belong to the subset assigned to the conditional item on the form or section.
  • When a fixed repeating section references a codelist subset, the codelist items selected as fixed columns must exist in the referenced codelist subset.
  • Each rule that references a codelist subset must only reference the codelist items that are part of the subset.
  • Each rule test for a rule that references a codelist subset must only reference the codelist items that are part of the subset.
  • A codelist subset is selected if for each item instance if:
    • The item has a codelist with defined subsets.
    • The Require codelist subset selection setting is enabled for the study.
  • If you import a study with an item that has a codelist subset that references a codelist that is not assigned to that item, during validation, you are prompted to select a valid codelist.
Review state
  • The maximum number of review states is not exceeded, and there are no duplicate State values.
  • State, Label, and Mnemonic are defined for a review state.
  • Label and Mnemonic are defined for each review stage.
  • Label and Mnemonic fields for a review state and each of its review stages have values for each required product locale. Values for an Oracle InForm product locale (English [United States] or Japanese [Japan]) are required if the locales specified for the study include a locale with the same language. For example, English translations are required if the study includes en-US or en-GB locales.
  • Label and Mnemonic for each review state are unique across locales.
  • Label and Mnemonic for each review stage are unique for each review state across locales.
  • Review stage names exist for each review stage and are unique within a review state.
  • Each review state has three defined review stages.
Workflow
  • A study object does not have multiple global conditions.
  • A workflow object does not have two outgoing arrows without a rule.
  • All study objects in a workflow reference study objects that still exist in the study. If validation fails due to an invalid workflow, go to the Workflow Diagram tab for the workflow with the issue, and right-click in the white space of the diagram and select Refresh Workflow to correct the issue.
  • A warning occurs if a rule contains the UpdateWorkflow action. The UpdateWorkflow action is not required for studies deployed to Oracle InForm release 6.1.1 or later.
  • Each workflow rule is connected to a study element or study event.
Data-entry rule
  • No rules are created on a linked item that is in multiple compound items.
  • The query message of a rule has 255 characters or fewer, not including the parameters.
  • For each data-entry rule, an item that triggers the rule is selected. If an item is not selected, you receive a warning during validation.
  • Each constant has a value (the length of the value must be greater than 0).
  • No email rules refer to items designated as Personal/Protected Health Information (PHI) in the subject or body of the email message.

Note:

If two rules (on different study objects) have the same name, in release 7.0 of the Oracle Central Designer application, you receive a warning during validation. Using the same rule name for rules on different study objects is not recommended, and future releases may not support the practice.
Function
  • All functions that are used in rules exist in the DLL file for user-defined functions.
  • A warning occurs if a study or library contains a user-defined function that uses an incorrect version of the Log4Net application.
  • A warning occurs if a study or library contains a user-defined function with an assembly that is:
    • Unsigned.
    • Not signed with a strong named signature.
    • Signed with an invalid or untrusted signature.

      Note:

      If you ignore the warning for a user-defined function with an assembly that requires signing with a strong named, valid, and trusted signature, an error occurs when the rule executes in the Oracle InForm application. For more information about user-defined function assemblies that require signing, see the Rules Reference Guide.
    • A warning occurs if a study or library contains a user-defined function with invalid references to ExternalFunctions.dll.
Unit
  • All units that are used in the study are in the units file. The file must have a symbol for each unit in each locale that is deployed, and a conversion map must exist to convert between the base unit and the conversion unit.
  • All units are translated for all of the supported locales for a study.
  • In the units file, unit names are 31 characters or fewer.
In-place revision
  • The study objects associated with in-place revisions exist.
  • No more than one in-place revision exists for each study object.
  • Every in-place revision is associated with an existing deployment instance and a study version.
Study administration data

General checks:

  • Each constant has a value (the length of the value must be greater than 0).

Item group checks:

  • Each item group contains one or more item.
  • Each item in an item group is a top-level item on at least one form in the study design.
  • Each item in an item group exists on a form in the study design.
  • Each item in an item group exists in only one item group.

Rights group checks:

  • Each rights group contains one or more item groups.
  • Each item group in a rights group exists in the study.

Signature group checks:

  • Each signature group contains a form.
  • Each form in a signature group exists in the study design.
  • For each signature group, a translation is provided for the Signature Meaning and Signature Text for each locale in the study.
Other Oracle reserved words are not used as RefNames of any study object or Aliases of data sets and data series.

Validation for special Oracle InForm forms and items

Validation area Error or warning
All special forms (Screening, Enrollment, Patient Identification, and Study Completion)

Error if:

  • The study contains multiple instances of the form.
  • The form contains multiple instances of any item.
  • The form is marked as repeating or appears in a repeating study event.
  • Required fields are not on the form.
  • The Special Forms property is defined on a section that is on the form.
Screening and Patient Identification forms

Error if:

  • (For a Screening form only) The form is used in multiple study events.
  • (For a Screening form only) The form contains a repeating section.
  • (For a Patient Identification form only) The Patient Number and Initials items are included on the form and are not together in either a section or the top-level form.
  • All items are not on the same section or form.
  • The item types for special items are not correct.

Warning if the special items are on a non-special form.
Enrollment form

Error if the:

  • Form is used in multiple study events.
  • Item types for special items are not correct.
  • Form contains a repeating section.

Warning if the special items are on a non-special form.
Study Completion form
  • Error if all items are not in the same form.
  • Warning if the special items are on a non-special form.
DOV item

Error if the item:

  • Is used multiple times in a study, unless it was copied using Copy > Link.

    Note:

    You can use the Copy > Link option to reuse the DOV item in a study. However, an error occurs if you use the DOV item multiple times in a study event, even if you copied it using Copy > Link.
  • Was copied using the Copy > Link option and pasted onto a form in the same study event.
  • Has an incorrect item type.
  • Is not on the first form in a study event.
  • Is in a repeating section or form.
  • Is in a common form or a section of a common form.
  • Is in a section in a repeating study event.
Randomization item
  • Error if the item appears multiple times in a study.
  • Error if the Patient Number and Randomization items are on the same section or form. If one item is on a section, the other item is allowed to be outside the section on the same form.
Patient Initials item Warning if the item has 4 characters.
Drop Out Reason item Error if the code for its codelist item has more than 47 characters.

Validation for coding

To be valid, a study must pass the following coding-related checks:

  • A form can contain only one copy of an item.
  • Items in a coding map must all be either in or not in a repeating section.
  • A coding map must include at least one target item.
  • A target item must be a top-level item or a child of a top-level compound item. It cannot be a child of a nested compound item and cannot be conditional on another item.
  • All query target items must be:
    • Top-level items.
    • Visible and available for editing in the Oracle InForm application. Items designated as query targets must not have the Display Override property set to ReadOnly or Hidden in the Oracle Central Designer application.
  • All items in a coding map, except the query target item, must be text items.
  • Each coding map is valid in the dictionary type from which it was created.
  • The dictionary metadata in the study CSML must be in the dictionaries that are supported in the Oracle Central Designer application.

Validation for monitoring forms

If you create a custom regulatory document form and a visit report form, the following must be true for the study to pass validation:

  • Only one regulatory document form and one visit report form exist in the study.
  • (For visit report forms only) The form contains a Date of Visit item that is marked as a Date of Visit special item and is the first item on the form.
  • If the study supports multiple locales, the regulatory document form and visit report form are translated for all locales. A warning occurs if the forms are missing translations for one or more locales.
  • The visit report form is not repeating.

Validation for data mappings

The type of data mapping, either CDD, CIS, or rules, determines whether the data mapping definition is validated against criteria for CDD data mappings, CIS data mappings, or no data mappings, respectively.

Validation area Must be true for successful validation
CDD data mappings -
Data type compatibility
  • All components of a date time item must be required and must not allow unknowns if the date time item is mapped to a data series with a data type of DateTime.
  • If one or more parts of a date time item are not required or allowed to be unknown, the data series to which the item is mapped must have a type of Text.
  • The length of an item mapped to a data series must not be longer than the value set in the DB Format Length custom property of the data series.
  • The precision of a float item mapped to a float data series must not be greater than the value set in the DB Format Float Precision custom property of the data series.
  • If a float item is mapped to an integer data series, the precision must be 0.
Date part and split date If any item is mapped to a data series with the split date option, all items mapped to the data series must use the split date option.
Target key types
  • Data series mapped to items in a repeating section cannot have a pivot target key type. Pivot tables are not supported for itemset data.
  • If the target key type of the data set is a pivot target key type, one (and only one) data series must be identified as the pivot column.
Data sets and data series Custom dimensions and custom dimension labels do not reference deleted codelists or codelist items.
CIS data mappings -
Block key and page key

The block key and page key must conform to the specifications of the data series for the block key item or page key item in the context panel:

  • The data type must convert to a compatible data type.
  • The length must be within the length specified in the DB Format Length CIS custom property.
  • If the data type of the data series is float, the precision must be within the precision specified in the DB Format Float Precision CIS custom property.
Context panel
  • A data mapping can have only one custom context panel.
  • The data series in a context panel must have data types of Text, Fixed, or Float.
  • The value of the Context Type property of a data series in a context panel cannot be:
    • Other context item if the value of the Is Key property is True.
    • Not a context item.
  • A context panel can have only one:
    • Subject key item.
    • Block key item.
    • Page key item.
    • Block repeat key item.
    • Page repeat key item.
  • For a subject key item, if the data type of the data series is Text, the value of the DB Format Length custom property cannot be greater than 80.
  • Data set aliases used in a context panel cannot be used in data sets for noncontext panels.
  • If the study contains a data set that is a custom context panel, and the study contains a common form with one or more items that are mapped to any data series, you must specify a value in the Shared Form Block Key custom property on the study design.
Data type compatibility
  • All components of a date time item must be required and must not allow unknowns if the date time item is mapped to a data series with a data type of DateTime.
  • If one or more parts of a date time item are not required or allowed to be unknown, the data series to which the item is mapped must have a type of Text.
  • The length of an item mapped to a data series must not be longer than the value set in the DB Format Length custom property of the data series.
  • The precision of a float item mapped to a float data series must not be greater than the value set in the DB Format Float Precision custom property of the data series.
  • If a float item is mapped to an integer data series, the precision must be 0.
Date part and split date If any item is mapped to a data series with the split date option, all items mapped to the data series must use the split date option.
Enrollment panel A data mapping can have only one enrollment panel.
Non-patient data panel The data series in a non-patient data panel cannot have any mapped items.
Other validation for CIS data mappings
  • The following CIS custom data series properties must be mutually exclusive:
    • Checklist and CIS Codelist.
    • Derived and Item Required.
  • RefNames of data sets and data series that are used for:
    • CIS data mappings must not be longer than 20 characters.
    • CDD data mappings must not be longer than 25 characters.
  • Aliases for data sets and data series must not be longer than 20 characters.
  • RefNames and aliases for data sets must be unique within a data mapping, and RefNames and aliases for data series must be unique within a data set. Checking for RefName and alias uniqueness is case insensitive; for example, the names BP and bp are considered identical.
  • The RefName and alias of a custom data dimension that is used as a subset key must not be the same as the RefName or alias of any data series in the data dimension.
  • If the value of the Is Key custom property of a data series is True, the value of the Item Required custom property must also be True.
  • If you do not create mappings for a CIS enrollment panel, the Oracle Central Designer application creates an enrollment panel from the items in the special screening and enrollment forms. The RefNames of the special screening and enrollment items used to create the enrollment panel must not be longer than 20 characters.
  • If a data set is marked as an enrollment or non-patient data panel, the value of the Detail Key Item, Detail Panel, Master Item, and Master Panel custom properties of all data series in the data set must not be True.
Data sets and data series Custom dimensions and custom dimension labels do not reference deleted codelists or codelist items.

Validation for in-place revisions

In order to validate an in-place revision, which compares the current potential baseline and previous baselines, baselines that have been deployed to LIVE/UAT must exist. For more information, see Delete a deployment package and Can I delete a validation baseline?

The following in-place revision changes cause validation warnings. If you make these changes using in-place revision, you must ensure that the changes do not result in data loss, do not compromise data integrity, and do not have regulatory impact.

  • Reduce the length of an alphanumeric, numeric, or float study object.
  • Reduce the minimum or maximum limit for a numeric or float study object.
  • Remove an item for which data was entered in Oracle InForm.

    Note:

    Oracle Central Designer does not check whether data has been entered for a study in Oracle InForm. We recommend creating or using an existing manual process to determine whether data loss, data integrity or regulatory impact occurs.
  • Modify the precision for a numeric or float study object.
  • Modify a codelist label.
  • Decrease the date range for a date control.
  • Remove a date part such as hours or minutes from a date control.
  • Modify item text to correct spelling or punctuation errors.
  • Add an item to an existing section.
  • Remove or modify the codelist subset for a codelist on a form.
  • Select a codelist subset for a codelist on a form.
  • Remove a codelist item from a subset that is assigned to a codelist on a form.
  • Remove a source from a dynamic grid.

The following in-place revision changes cause validation errors. You cannot deploy your study successfully if you make these changes by performing an in-place revision.

  • Remove a unit selection for an item.
  • Modify a codelist selection value.
  • Modify a fixed repeating section by doing the following:
    • Add an additional row.
    • Change a predefined value.
    • Remove a row.
    • Rearrange rows.
    • Change an existing item cell from non-blank to blank.
    • Change an existing item cell from blank to non-blank.
    • Add new items that have blank cells.
  • Modify a dynamic grid section by doing the following:
    • Change the section from dynamic to not dynamic.
    • Remove an item from the source form or section referenced in the dynamic grid section, and apply the in-place revision to the source object, but not to the dynamic grid section.
    • On the Design tab of the form or the Properties tab for the form, modify an item on the source form or section referenced in the dynamic grid section, and apply the in-place revision to the source object, but not to the dynamic grid section.

      Note:

      If you make these changes on the forms' Layout tab, you need to apply the in-place revision to the source object or the dynamic grid section, but not both.
    • Modify an item on the source form or section referenced in the dynamic grid section, and apply the in-place revision to the dynamic grid section, but not to the source object.
    • Add an item to the source form or section referenced in the dynamic grid section, add the item to the dynamic grid section, and apply the in-place revision to the dynamic grid section, but not to the source object.
    • Add a source form or section to the study, add its items to the dynamic grid section, and apply an in-place revision to the dynamic grid section.

      Note:

      This is not possible because, even though adding an item to a dynamic grid section is a supported in-place revision change, adding a form or section must be done by creating a new study version. You cannot deploy a study with both types of changes.
    • Change the type of item mapping (item level or data point mapping).
    • Change the codelist item mapped for the source item, but that codelist item does not exist in a deployed version of the source, and in-place revision is applied to the dynamic grid but not the source.
    • Codelist item used by a dynamic grid was removed and in-place revision applied to the source but not on dynamic grid.
    • Codelist subset for an item in item level mapping does not match between source and target, and in-place revision is not applied both to the source and the dynamic grid.
  • Modify the structure of a control by adding a level of nesting or changing a radio control to a pull-down control.
  • Remove a special item.
  • Add a section to a form.
  • Remove a section from a form.

Validation for custom events

Validation area Must be true for successful validation
Custom events
  • A warning occurs if you're deploying the study with custom events to an Oracle InForm release prior to 6.2.
  • If a custom event has a prerequisite custom event, the prerequisite has a lower priority group number so that it runs first.
  • Each custom event has one or more triggers.
  • Each custom event has one or more results.
  • Each custom event has a destination name, endpoint name and priority group.
  • The trigger or result is mapped to an item that is nested fewer than six levels.
  • For a custom event with a selected Integration type, a warning occurs if the following values do not match.
    • Integration Type in Oracle Central Designer must match Integration Type in Oracle Central Designer Administrator.
    • Endpoint Name in Oracle Central Designer must match Endpoint Name in Oracle Central Designer Administrator.
    • Map to name in Oracle Central Designer must match a Map to name in Oracle Central Designer Administrator.
    • Result Custom Data Name in Oracle Central Designer must match a Custom Data Name in Oracle Central Designer Administrator.
    • Result Custom Data Value in Oracle Central Designer must match a Custom Data Value in Oracle Central Designer Administrator.
Custom event triggers
  • All study objects in each trigger exist in the study design.
  • The path for every study object in each trigger matches the study design.
  • For a trigger referencing a codelist, the selected codelist must have codelist items defined, and the codelist items must exist in the study design.
  • If a trigger in custom event references a repeating visit, all triggers in that custom event refer to the same repeating visit.
  • If a trigger in custom event references a repeating form, all triggers in that custom even refer to the same repeating form.
  • If a trigger in custom event references a repeating section, all triggers in that custom event should refer to the same repeating section.
  • Triggers only reference repeating sections.
  • For a trigger on a form with an Event type of Review State, the review state and review stage objects exist in the study design.
  • For a trigger with an Event type of ValueMatch on an integer or float item without a codelist, the value that you enter in the Value to Compare field must match the item type. For example, if you create the trigger on a float item, you must enter a float value in the Value to Compare field.
  • For a trigger on an item with an Event type of ValueMatch, the value that you enter in the Value to Compare field must not exceed the value of the Length property for the item.
  • For a trigger on a float item with an Event type of ValueMatch, the value that you enter in the Value to Compare field must include the exact precision specified in the Precision property for the item.
Custom event results
  • All study objects in each result exist in the study design.
  • The path for every study object in a result matches the study design.
  • If a custom event has an Integration type, the specified Integration type, Map to name, Result data name, and Result data value in the result corresponds to the available options in the Oracle Central Designer Administrator.
  • Results only reference repeating sections.
Custom event In-place revisions
  • The path for study objects referenced in the custom event trigger is valid path in the target study version.
  • The path for study objects referenced in the custom event result is valid path in the target study version.
  • For a trigger on a codelist with an Event type of Value Match, the codelist item that you select in the Value to Compare field exists on the selected codelist item in the target study version.
  • The review state or review stage referenced in the custom event trigger is defined for the target study version.

Some information is not validated. For more information, see What information is not validated?

Parent topic: Validation