Page History

If a logically related grouping of data is in scope for a domain defined in this guide but not all data can be represented using the domain variables, then data may be represented by adding variables from the SDTM to the domain or by using a Supplemental Qualifier dataset related to the domain.

Once confirmed, determine whether adding a variable from the SDTM will fit the need. If adding a variable from the SDTM meets the need, then a Supplemental Qualifier dataset will not be implemented. Supplemental Qualifier datasets will only be implemented for domains when data are not in scope for a variable defined in the SDTM. 

The overall process for extending a domain is as follows:

1. Select variables for the domain from the SDTM. Selection of variables must align with SDTM usage restrictions.The general approach for adding variables to a domain from the SDTM is to:
   1. Include applicable Identifier variables.
   2. Include applicable Qualifier variables in alignment with the SDTM General Observation Classes.
   3. Include applicable Timing variables.
   4. Apply the domain code to the variables as appropriate by replacing all variable prefixes (shown in the SDTM as “--“) with the domain code.
   5. Set the order of variables consistent with the order defined in the SDTM.
   6. Adjust the labels of the variables only as appropriate to convey their meaning in the context of the data in domain. Use title case for all labels.

   7. Ensure that appropriate standard variables are being properly applied by comparing their use in the domain to their use in related TIG domains.

2. Place any NSVs in a Supplemental Qualifier dataset when variables cannot be selected from the SDTM. 

How to Read a Domain Specification - SDTMIG v3.4 - Wiki (cdisc.org)

A domain specification table includes rows for all required and expected variables for a domain and for a set of permissible variables. The permissible variables do not include all the variables that are allowed for the domain; they are a set of variables that the SDS Team considered likely to be included. The columns of the table are:

• Variable Name
  • For variables that do not include a domain prefix, this name is taken directly from the SDTM.
  • For variables with a "--" placeholder in the SDTM, the "--" is replaced by the 2-character domain code.
• Variable Label: A longer name for the variable  
  
  • This may be the same as the label in the SDTM, or it may be customized for the domain.
  • Sponsors should create an appropriate label if they include in a dataset an allowable variable not in the domain specification.
• Type: One of the 2 SAS datatypes, "Num" or "Char".  These values are taken directly from the SDTM.
• Controlled Terms, Codelist, or Format
  • Controlled Terms
    • As noted in the table note, an asterisk (*) indicates that the variable may be subject to controlled terminology.
      • The controlled terminology might be of a type that would inherently be sponsor-defined.
      • The controlled terminology might be of a type that could be standardized, but for which a codelist not yet been developed.
      • The controlled terminology might be terminology specified in value-level metadata.
    • The name of an external code system (e.g., MedDRA) will be listed in plain text.
  • Codelist 
    • A hyperlinked codelist name in parentheses indicates that the variable is subject to the CDISC Controlled Terminology in the named codelist.
    • Multiple hyperlinked codelist names indicate that the variable is subject to 1 or more of the named codelists from CDISC Controlled Terminology. If multiple codelists are in use for a single domain, value-level metadata would indicate where each codelist is applicable.
    • A hyperlinked codelist name and an asterisk (*) indicate that the variable is subject to either the named codelist from the CDISC Controlled Terminology or to an external dictionary. The specific dictionary is identified in the metadata.
  • Format: "ISO 8601 datetime or interval" or "ISO 8601 duration" in plain text indicates that the variable values should be formatted in conformance with that standard.
• Role: This is taken directly from the SDTM. Note that if a variable is either a Variable Qualifier or a Synonym Qualifier, the SDTM includes the qualified variable, but SDTMIG domain specifications do not.
• CDISC Notes may include any of the following:
  • A description of what the variable means
  • Information about how this variable relates to another variable
  • Rules for when or how the variable should be populated, or how the contents should be formatted
  • Examples of values that might appear in the variable. Such examples are only examples, and although they may be CDISC Controlled Terminology values, their presence in a CDISC Note should not be construed as definitive. For authoritative information on CDISC Controlled Terminology, consult https://www.cancer.gov/research/resources/terminology/cdisc.
• Core: Contains 1 of the 3 values—"Req", "Exp", or "Perm"—explained further in Section 4.1.5, SDTM Core Designations.

Variables in the domains should be ordered with identifiers first, followed by the topic, qualifier, and timing variables.

SDTM - The SDTM Standard Domain Models

Final domains will be published only in an SDTM implementation guide (this guide or another implementation guide, e.g., SDTMIG for Medical Devices). Therapeutic-area standards projects and other projects may develop proposals for additional domains. Draft versions of these domains may be made available in the CDISC wiki in the SDTM Draft Domains space (https://wiki.cdisc.org/display/SDD/SDTM+Draft+Domains+Home).

These general rules apply when determining which variables to include in a domain:

• The Identifier variables, STUDYID, USUBJID, DOMAIN, and --SEQ are required in all domains based on the general observation classes. Other Identifiers may be added as needed.
• Any Timing variables are permissible for use in any submission dataset based on a general observation class except where restricted by specific domain assumptions.
• Any additional Qualifier variables from the same general observation class may be added to a domain model except where restricted by specific domain assumptions.
• Sponsors may not add any variables other than those described in the preceding 3 bullets. The SDTM allows for the inclusion of a sponsor's non-SDTM variables using the Supplemental Qualifiers special-purpose dataset structure, described in Section 8.4, Relating Non-standard Variable Values to a Parent Domain. As the SDTM continues to evolve, certain additional standard variables may be added to the general observation classes. 
• Standard variables must not be renamed or modified for novel usage. Their metadata should not be changed.
• A Permissible variable should be used in an SDTM dataset wherever appropriate.  
  • If a study includes a data item that would be represented in a Permissible variable, then that variable must be included in the SDTM dataset, even if null. Refer to the Define-XML standard (available at https://www.cdisc.org/standards/data-exchange/define-xml) for additional details on how to manage no data availability.
  • If a study did not include a data item that would be represented in a Permissible variable, then that variable should not be included in the SDTM dataset and should not be declared in the Define-XML document.

SEND

Additional timing variables (see SDTM v1.5 Table 2.2.5; https://www.cdisc.org/standards/foundational/sdtm/) can be added as needed to a standard domain model based on the 3 general observation classes. Timing variables can be added to special-purpose domains only where specified in the SENDIG domain model assumptions. Timing variables cannot be added to SUPP-- datasets or to RELREC (see Section 8, Representing Relationships and Data). Timing variables cannot be added to the Trial Design Model datasets (see Section 7, Trial Design Model Datasets).