If data are in scope for domain dataset defined in this guide, but not all data points for an observation can be represented using existing variables, then variables may be added from the SDTM or included in a related supplemental dataset.

A custom domain may only be created when data are different in nature and are not in scope for domains described in this guide. Custom domains will be used to represent logically related observations based on the scientific subject matter of the data and will not be created based on:

• The timing of collected observations (e.g., all vital signs measurements will be represented in domain Vital Signs (VS) irrespective of when measurements occurred).
• How collected data are used (e.g., all vital signs measurements will be represented in domain VS and a custom "safety" domain will not be created for measurements used to assess safety).
• Data collection methodology (e.g., all vital signs measurements will be represented in domain VS irrespective of whether measurements were recorded using separate CRFs).

Prior to creating a custom domain, confirm that none of the existing published domains will fit the need. Once confirmed, drafting a specification upfront, using conventions in Section x.x, How to Read Domain Specifications, is recommended to ensure expectations for the custom domain are clear. Custom domains and corresponding specifications must be created based on the three general observation classes, Interventions, Events, and Findings, described in the SDTM. In most cases, the choice of observation class appropriate to a specific collection of data can be easily determined according to descriptions of these classes in the SDTM. The majority of data, which typically consists of measurements or responses to questions, usually at specific visits or time points, will fit the Findings general observation class. 

The overall process for creating a custom domain is as follows:

1. Establish a common topic or topics for the data. The common topic or topics will reflect a collection of logically related observations based on the scientific subject matter of the data.
   1. If more than one topic is identified, then more than one domain may be needed.
      1. In such cases, consider whether topics are hierarchical in nature where data for one topic must be observed before data for a second topic can be observed. If a hierarchical relationship between topics exists, then paired domains will be created (e.g., Pharmacokinetics Concentrations (PC) and Pharmakinetics Parameters (PP) is an established domain pair). Relationships between records in paired domains may then be represented in the Related Records (RELREC) dataset as appropriate.
2. Categorize data within the domain using Grouping Qualifier variables (e.g., --CAT, --SCAT) and identify other Qualifiers applicable to the data (e.g., --METHOD, --SPEC) as appropriate.
3. Look for a domain within this guide to serve as a prototype. If no domain seems appropriate, choose the general observation class in the SDTM (Interventions, Events, or Findings) that best fits the data given the topic of the observations.
4. Select variables for the domain from the SDTM. Selection of variables must align with SDTM Usage Restrictions. As illustrated in the following figure, the general approach for selecting variables for a custom domain is to:
   1. Include applicable Identifier variables. Identifier variables STUDYID, USUBJID, DOMAIN, and --SEQ are required in all domains based on the general observation classes. Additional Identifiers may be added as needed.
   2. Include the Topic variable from the SDTM general observation class (e.g., --TESTCD for Findings). 
   3. Include the relevant Qualifier variables from the identified SDTM general observation class.
   4. Include the applicable SDTM Timing variables. In general, the domain must have at least one timing variable.
   5. Determine the two-character domain code.
      1. The domain code add domain naming rules here
   6. Apply the domain code to the appropriate variables in the domain by replacing all variable prefixes (shown in the SDTM as “--“) with the domain code.
   7. Set the order of variables consistent with the order defined in the SDTM for the general observation class.
   8. Adjust the labels of the variables only as appropriate to convey their meaning in the context of the data in the newly created domain. Use title case for all labels.

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

   10. Place any non-SDTM variables in a Supplemental Qualifier dataset. 

If data cannot be represented in a domain dataset defined in this guide, then a custom domain may be used. A custom domain may only be created when data are different in nature and are not in scope for domains described in this guide. Custom domains will be used to represent logically related observations based on the scientific subject matter of the data and will not be created based on:

• The timing of collected observations (e.g., all vital signs measurements will be represented in domain Vital Signs (VS) irrespective of when measurements occurred).
• How collected data are used (e.g., all vital signs measurements will be represented in domain VS and a custom "safety" domain will not be created for measurements used to assess safety).
• Data collection methodology (e.g., all vital signs measurements will be represented in domain VS irrespective of whether measurements were recorded using separate CRFs).

Prior to creating a custom domain, confirm that none of the existing published domains will fit the need. Once confirmed, drafting a specification upfront, using conventions in Section x.x, How to Read Domain Specifications, is recommended to ensure expectations for the custom domain are clear. Custom domains and corresponding specifications must be created based on the three general observation classes, Interventions, Events, and Findings, described in the SDTM. In most cases, the choice of observation class appropriate to a specific collection of data can be easily determined according to descriptions of these classes in the SDTM. The majority of data, which typically consists of measurements or responses to questions, usually at specific visits or time points, will fit the Findings general observation class. 

The overall process for creating a custom domain is as follows:

1. Establish a common topic or topics for the data. The common topic or topics will reflect a collection of logically related observations based on the scientific subject matter of the data.
   1. If more than one topic is identified, then more than one domain may be needed.
      1. In such cases, consider whether topics are hierarchical in nature where data for one topic must be observed before data for a second topic can be observed. If a hierarchical relationship between topics exists, then paired domains will be created (e.g., Pharmacokinetics Concentrations (PC) and Pharmakinetics Parameters (PP) is an established domain pair). Relationships between records in paired domains may then be represented in the Related Records (RELREC) dataset as appropriate.
2. Categorize data within the domain using Grouping Qualifier variables (e.g., --CAT, --SCAT) and identify other Qualifiers applicable to the data (e.g., --METHOD, --SPEC) as appropriate.
3. Look for a domain within this guide to serve as a prototype. If no domain seems appropriate, choose the general observation class in the SDTM (Interventions, Events, or Findings) that best fits the data given the topic of the observations.
4. Select variables for the domain from the SDTM. Selection of variables must align with SDTM Usage Restrictions. As illustrated in the following figure, the general approach for selecting variables for a custom domain is to:
   1. Include applicable Identifier variables. Identifier variables STUDYID, USUBJID, DOMAIN, and --SEQ are required in all domains based on the general observation classes. Additional Identifiers may be added as needed.
   2. Include the Topic variable from the SDTM general observation class (e.g., --TESTCD for Findings). 
   3. Include the relevant Qualifier variables from the identified SDTM general observation class.
   4. Include the applicable SDTM Timing variables. In general, the domain must have at least one timing variable.
   5. Determine the two-character domain code.
      1. The domain code add domain naming rules here
   6. Apply the domain code to the appropriate variables in the domain by replacing all variable prefixes (shown in the SDTM as “--“) with the domain code.
   7. Set the order of variables consistent with the order defined in the SDTM for the general observation class.
   8. Adjust the labels of the variables only as appropriate to convey their meaning in the context of the data in the newly created domain. Use title case for all labels.

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

   10. Place any non-SDTM variables in a Supplemental Qualifier dataset. 

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).