Page History

A custom domain may only be created if the data are different in nature and do not fit into an existing published domain. If a specification does not exist in this guide to 

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,

data collected or derived 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 implementation, but this is not required. 

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

...