Page History
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 out of not in scope for domains described in this guide. It is recommended that a specification be drafted prior to implementing a custom domain dataset using conventions described in Section x.x. 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 the Vital Signs (VS) domain irrespective of when measurements occurred)
- How collected data are used (e.g., all vital signs measurements will be represented in 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 VS irrespective of whether measurements were recorded using separate CRFs, a medical device like a fitness tracker, or an electronic diary)
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 2.8.1, How to Read Domain Specifications to support expected implementation, but this is not requiredis recommended to ensure expectations for the custom domain are clear. Custom domains and corresponding specifications may must be created based on the three 3 general observation classes (i.e.,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 data—which typically consists of measurements or responses to questions, usually at specific visits or time points, will points—will fit the Findings general observation class. Jira showSummary false server Issue Tracker (JIRA) serverId 85506ce4-3cb3-3d91-85ee-f633aaaf4a45 key TOBA-796
These general rules apply when determining which variables to include in The overall process for creating a custom domain is as follows:
- 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.
- In general, the domain must have at least one timing variable. 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 three bullets. The SDTM allows for the inclusion of non-SDTM variables using the Supplemental Qualifiers special-purpose dataset structure.
- 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.
- 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.
Creating a New Domain - SDTMIG v3.4 - Wiki (cdisc.org)
This section describes the overall process for creating a custom domain, which must be based on 1 of the 3 SDTM general observation classes. The number of domains submitted should be based on the specific requirements of the study. To create a custom domain,
...
- Establish a domain of a common topic; that is, where the nature of the data is the same rather than by a specific method of collection (e.g., electrocardiogram). Group and separate data within the domain using --CAT, --SCAT, --METHOD, --SPEC, --LOC, and so on, as appropriate. Examples of different topics are: microbiology, tumor measurements, pathology/histology, vital signs, and physical exam results.
- Do not create separate domains based on time; rather, represent both prior and current observations in a domain (e.g., CM for all non-study medications). Note that Adverse Events (AE) and Medical History (MH) are an exception to this best practice because of regulatory reporting needs.
- How collected data are used (e.g., to support analyses and/or efficacy endpoints) must not result in the creation of a custom domain. For example, if blood pressure measurements are endpoints in a hypertension study, they must still be represented in the Vital Signs (VS) domain, as opposed to a custom “efficacy” domain. Similarly, if liver function test results are of special interest, they must still be represented in the Laboratory Tests (LB) domain.
- Data that were collected on separate CRF modules or pages may fit into an existing domain (e.g., as separate questionnaires into the QS domain, prior and concomitant medications in the CM domain).
- If it is necessary to represent relationships between data that are hierarchical in nature (e.g., a parent record must be observed before child records), then establish a domain pair (e.g., MB/MS, PC/PP). Note: Domain pairs have been modeled for microbiology data (MB/MS domains) and pharmacokinetics (PK) data (PC/PP domains) to enable dataset-level relationships to be described using RELREC. The domain pair uses DOMAIN as an identifier to group parent records (e.g., MB) from child records (e.g., MS) and enables a dataset-level relationship to be described in RELREC. Without using DOMAIN to facilitate description of the data relationships, RELREC, as currently defined, could not be used without introducing a variable that would group data like DOMAIN.
...
- 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.
- If more than 1 topic is identified, then more than 1 domain may be needed.
- In such cases, consider whether topics are hierarchical in nature, where data for 1 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 Pharmacokinetics 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.
- If more than 1 topic is identified, then more than 1 domain may be needed.
- 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.
- 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.
- 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:
...
- 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.
- Include the
...
- Topic variable from the
...
- SDTM general observation class (e.g., --TESTCD for Findings)
...
- .
...
- Include the relevant
...
- Qualifier variables from the identified SDTM general observation class
...
- .
...
- Include the applicable SDTM Timing variables. In general, the domain must have at least 1 timing variable.
- Determine the 2-character domain code
...
- .
...
...
Ensure that appropriate standard variables are being properly applied by comparing their use in the custom domain to their use in standard domains.
...
Describe the dataset within the Define-XML document. See Section 3.2, Using the CDISC Domain Models in Regulatory Submissions — Dataset Metadata.
...
Place any non-standard (SDTM) variables in a Supplemental Qualifier dataset. Mechanisms for representing additional non-standard qualifier variables not described in the general observation classes and for defining relationships between separate datasets or records are described in Section 8.4, Relating Non-standard Variable Values to a Parent Domain.
- To eliminate the risk of using a name that CDISC later determines to have a different meaning, domain codes beginning with the letters X, Y, and Z have been reserved for the creation of custom domains. Any letter or number may be used in the second position. The use of codes beginning with X, Y, or Z is optional, and not required for custom domains.
- Apply the
...
This section describes the overall process for creating a custom domain, which must be based on 1 of the 3 SDTM general observation classes. The number of domains submitted should be based on the specific requirements of the study. To create a custom domain,
...
- Establish a domain of a common topic; that is, where the nature of the data is the same rather than by a specific method of collection (e.g., electrocardiogram). Group and separate data within the domain using --CAT, --SCAT, --METHOD, --SPEC, --LOC, and so on, as appropriate. Examples of different topics are: microbiology, tumor measurements, pathology/histology, vital signs, and physical exam results.
- Do not create separate domains based on time; rather, represent both prior and current observations in a domain (e.g., CM for all non-study medications). Note that Adverse Events (AE) and Medical History (MH) are an exception to this best practice because of regulatory reporting needs.
- How collected data are used (e.g., to support analyses and/or efficacy endpoints) must not result in the creation of a custom domain. For example, if blood pressure measurements are endpoints in a hypertension study, they must still be represented in the Vital Signs (VS) domain, as opposed to a custom “efficacy” domain. Similarly, if liver function test results are of special interest, they must still be represented in the Laboratory Tests (LB) domain.
- Data that were collected on separate CRF modules or pages may fit into an existing domain (e.g., as separate questionnaires into the QS domain, prior and concomitant medications in the CM domain).
- If it is necessary to represent relationships between data that are hierarchical in nature (e.g., a parent record must be observed before child records), then establish a domain pair (e.g., MB/MS, PC/PP). Note: Domain pairs have been modeled for microbiology data (MB/MS domains) and pharmacokinetics (PK) data (PC/PP domains) to enable dataset-level relationships to be described using RELREC. The domain pair uses DOMAIN as an identifier to group parent records (e.g., MB) from child records (e.g., MS) and enables a dataset-level relationship to be described in RELREC. Without using DOMAIN to facilitate description of the data relationships, RELREC, as currently defined, could not be used without introducing a variable that would group data like DOMAIN.
...
- domain code to the appropriate variables in the domain
...
- by replacing all variable prefixes (shown in the
...
- SDTM as “--“) with the domain code.
...
- Set the order of variables consistent with the order defined in the SDTM for the
...
- general observation class.
- 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
...
- .
- Ensure that appropriate standard variables are being properly applied by comparing their use in the custom domain to their use in
...
- related TIG domains.
- Place any non-
...
- SDTM variables
in a Supplemental Qualifier dataset.Jira showSummary false server Issue Tracker (JIRA) serverId 85506ce4-3cb3-3d91-85ee-f633aaaf4a45 key TOBA-795
...
Excerpt Include Figure.Creating a New Domain Figure.Creating a New Domain nopanel true
Pagenav
Overview
Content Tools