How to Create New Specifications

Custom domains and corresponding specifications may be created based on the three general observation classes described in the SDTM.

New domain specifications may be created when domain specifications in this guide don't exist

The General Observation Classes - SDTMIG v3.4 - Wiki (cdisc.org)

Most subject-level observations collected during the study should be represented according to 1 of the 3 SDTM general observation classes: Interventions, Events, or Findings. The lists of variables allowed to be used in each of these can be found in the SDTM.

• The Interventions class captures investigational, therapeutic, and other treatments that are administered to the subject (with some actual or expected physiological effect) either as specified by the study protocol (e.g., exposure to study drug), coincident with the study assessment period (e.g., concomitant medications), or self‑administered by the subject (e.g., use of alcohol, tobacco, or caffeine).
• The Events class captures planned protocol milestones such as randomization and study completion, and occurrences, conditions, or incidents independent of planned study evaluations occurring during the trial (e.g., adverse events) or prior to the trial (e.g., medical history).
• The Findings class captures the observations resulting from planned evaluations to address specific tests or questions (e.g., laboratory tests, ECG testing, questions listed on questionnaires).

In most cases, the choice of observation class appropriate to a specific collection of data can be easily determined according to these descriptions. 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. Additional guidance on choosing the appropriate general observation class is provided in Section 8.6.1, Guidelines for Determining the General Observation Class.

General assumptions for use with all domain models and custom domains based on the general observation classes are described in Section 4, Assumptions for Domain Models; specific assumptions for individual domains are included with the domain models.

Datasets Other than General Observation Class Domains - SDTMIG v3.4 - Wiki (cdisc.org)

The SDTM includes 4 types of datasets other than those based on the general observation classes:

• Domain datasets with subject-level data that do not conform to 1 of the 3 general observation classes. These include Demographics (DM), Comments (CO), Subject Elements (SE), and Subject Visits (SV), and are described in Section 5, Models for Special-purpose Domains.
• Trial Design Model (TDM) datasets, which represent information about the study design but do not contain subject data. These include datasets such as Trial Arms (TA) and Trial Elements (TE) and are described in Section 7, Trial Design Model Datasets.
• Relationship datasets, such as the RELREC and SUPP-- datasets. These are described in Section 8, Representing Relationships and Data.
• Study Reference datasets include Device Identifiers (DI) and Non-host Organism Identifiers (OI). These provide structures for representing study-specific terminology used in subject data. These are described in Section 9, Study References.

Datasets and Domains - SENDIG v3.1.1 - Wiki (cdisc.org) 

When determining which general-observation class domain model is appropriate for reporting specific observations, refer to the domain definition included in the Assumptions section for each domain model (see Section 6, Domain Models Based on the General Observation Classes).

SDTM Datasets and Domains:

The SDTM lists only the name, label, and type, with a set of brief CDISC guidelines that provide a general description for each variable.

A custom domain may only be created if the data are different in nature and do not fit into an existing published domain. If data cannot be represented in a dataset defined in this guide, then a custom dataset may be used. It is recommended that a specification with the dataset name, record structure, and a domain table specification be drafted prior to support implementation, but this is not required. 

In general, all domains based on the 3 general observation classes should have at least 1 timing variable. In the events 

Timing variables (SDTM Section 3.1.5, Timing Variables for All Classes) are an essential component of all SDTM subject-level domain datasets. In general, all domains based on the 3 general observation classes should have at least 1 timing variable. In the Events or Interventions general observation class, this could be the start date of the event or intervention. In the Findings observation class, where data are usually collected at multiple visits, at least 1 timing variable must be used.

Custom domain specifications and, by extension, custom datasets should be designed in the following steps:

1. Confirm that none of the domains published in this guide will fit the need.
2. If a domain does not exist in this guide: 
   • 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.
   • 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.

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,

1. Confirm that none of the existing published domains will fit the need. A custom domain may only be created if the data are different in nature and do not fit into an existing published 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.
2. Check the SDTM Draft Domains area of the CDISC wiki (https://wiki.cdisc.org/display/SDD/SDTM+Draft+Domains+Home) for proposed domains developed since the last published version of the SDTMIG. These proposed domains may be used as custom domains in a submission.
3. Look for an existing, relevant domain model to serve as a prototype. If no existing model seems appropriate, choose the general observation class (Interventions, Events, or Findings) that best fits the data by considering the topic of the observation. As illustrated in the following figure, the general approach for selecting variables for a custom domain is:
1. Select and include the required identifier variables (e.g., STUDYID, DOMAIN, USUBJID, --SEQ) and any permissible Identifier variables from the SDTM. 
2. Include the topic variable from the identified general observation class (e.g., --TESTCD for Findings) in the SDTM. 
3. Select and include the relevant qualifier variables from the identified general observation class in the SDTM. Variables belonging to other general observation classes must not be added.
4. Select and include the applicable timing variables in the SDTM.
5. Determine the domain code, one that is not a domain code in the CDISC Controlled Terminology SDTM Domain Abbreviations codelist (see  https://datascience.cancer.gov/resources/cancer-vocabulary/cdisc-terminology). If it is desired to have this domain code be part of CDISC Controlled Terminology, submit a request at https://ncitermform.nci.nih.gov/ncitermform/?version=cdisc. The sponsor-selected, 2‑character domain code should be used consistently throughout the submission. AD, AX, AP, SQ, and SA may not be used as custom domain codes.
6. Apply the 2-character domain code to the appropriate variables in the domain. Replace all variable prefixes (shown in the models 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 properly convey the meaning in the context of the data being submitted in the newly created domain. Use title case for all labels (title case means to capitalize the first letter of every word except for articles, prepositions, and conjunctions).

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

10. Describe the dataset within the Define-XML document. See Section 3.2, Using the CDISC Domain Models in Regulatory Submissions — Dataset Metadata.

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

Figure. Creating a New Domain