Standards rules validate the structure of standard definitions including the datasets, variables, and value-level metadata that describe how a study should be organized. Use them to enforce consistency in your standard library or to catch problems in a study's in-progress metadata before the data itself gets validated.
Scopes
Every Standards rule runs at one of two scopes, set on the Assignments tab. The scope determines what your rule sees and when it executes.
Scope | What it does | Use it when |
Standard Level | Runs against the standard itself. These standard are your maintained catalog of custom CDISC and non-CDISC standards. | Doing standard library QC, enforcing business rules across all standards. |
Study Level | Runs against a study's metadata as it's defined in the study spec. | Validating study adaptations or enforcing therapeutic area-specific conventions. |
For how a Standards rule gets assigned to standards and studies, see Understanding rule properties and assignments, which jumps straight to the Standards section.
Standard Level
At a high level, a Standard Level rule operates on a standard and the controlled terminology recommended for it. Use the conceptual view below to orient yourself, then refer to the detailed data model for the exact tables and columns available in your rule.
Conceptual model
Detailed data model
Each table is one kind of object you can write a rule against; the column labels in brackets are how the field surfaces in the UI on the Standard and/or Terminology.
Foreign-key columns appear in blue. The 1 and N markers indicate the cardinality of each relationship.
Study Level
A Study Level rule queries a study spec, the in-progress study metadata for a data package. A study spec is configured to a standard and a controlled terminology; the terminology applied to the study may differ from the standard's recommended terminology.
Note For ADaM specs, only the SDTM controlled terminology configured to the data package is available to your rule. ADaM controlled terminology is not available.
Conceptual model
Detailed data model
Each table is one kind of object you can write a rule against; the column labels in brackets are how the field surfaces in the rule editor and in the Change Log.
Foreign-key columns appear in blue. The 1 and N markers indicate the cardinality of each relationship.
Pointing the finding: Tab and Column
The Tab and Column control where a finding takes the user. When someone clicks View Issue from the Issues tab, the validator opens the Tab you selected and highlights the cell identified by the Column. You set both in the rule's Logic section, alongside the Language.
Tab — "Select the tab being validated." The tab that View Issue opens: Datasets, Variables, Value Level, Methods, Comments, Codelist, or Terms.
Column — "Select the column being validated." The cell that gets highlighted when the user clicks View Issue.
For a finding to land on the right row of that Tab, your SELECT statement must return the Tab's key column(s). For example, to point findings at the Variables tab, include dataset_name and name in the SELECT:
Tab being validated | Must be in the SELECT |
Datasets |
|
Variables |
|
Value Level |
|
Methods |
|
Comments |
|
Codelist |
|
Terms |
|
Examples
Below are example rules for Target = Standards.
Example 1 — variable name follows naming conventions for its data type
SELECT v.dataset_name, v.name, v.data_type FROM meta.standard_variable vWHERE v.name IS NOT NULLAND ((UPPER(v.name) NOT LIKE '%DTTM' AND v.data_type = 'datetime') OR (UPPER(v.name) NOT LIKE '%DAT' AND v.data_type = 'date') OR (UPPER(v.name) NOT LIKE '%TIM' AND v.data_type = 'time'))
Returns records where the variable name violates naming conventions based on its type: datetime should end in *DTTM, date should end in *DAT, and time should end in *TIM.
Example 2 — dataset Owner/Contact must be set
SELECT name FROM meta.define_dataset WHERE "Owner/Contact" IS NULL
Returns datasets where Owner/Contact is null. Owner/Contact is an example of a spec extension.
Example 3 — every dataset must define a SUBJID variable
SELECT d.name, v.name AS var_name FROM meta.standard_dataset d LEFT JOIN meta.standard_variable v ON d.name = v.dataset_name AND UPPER(TRIM(v.name)) = 'SUBJID'WHERE var_name IS NULL
Returns datasets that do not contain a SUBJID variable on the Variables tab.
Table glossary
Each table is one kind of object you can write a rule against. The standard_* tables describe a standard; the define_* tables describe a study's configured spec. A Study Level rule can query both.
The terminology_code_list and terminology_term tables appear at both scopes, but they represent different things: at the Standard Level they are the standard's recommended controlled terminology, and at the Study Level they are the controlled terminology configured to the study.
Standard Level tables
Table | Represents |
| Datasets in a standard (Datasets tab). |
| Variables in a standard (Variables tab). |
| Value-level metadata (Value Level tab). |
| Computational methods (Methods tab). |
| Comments (Comments tab). |
| Supporting documents (Documents, on the Properties tab). |
| Codelists of the recommended terminology (Codelist tab). |
| Terms within those codelists (Terms tab). |
Study Level tables
Available in addition to the standard_* tables above.
Table | Represents |
| Datasets in the study spec. |
| Variables in the study spec. |
| Value-level metadata in the study spec. |
| Computational methods in the study spec. |
| Comments in the study spec. |
| Supporting documents in the study spec. |
| Codelists in the study's Define spec. |
| Terms within those Define-spec codelists. |
| External dictionaries referenced by codelists. |
| Codelists of the controlled terminology configured to the study (not the standard's recommended CT). |
| Terms within the study's configured controlled terminology. |