This document describes the Study Data Tabulation Model (SDTM), which defines a standard structure for study data tabulations. This document, which supersedes all prior versions, includes numerous changes from the prior SDTM v1.6, described in Section 8.1, Changes From SDTM v1.6 to SDTM v1.7.

This document is intended for companies and individuals involved in the collection, preparation, and analysis of study data which may be submitted to regulatory authorities. Guidance, specifications, and regulations for the application of this model are provided separately in the Implementation Guides (IGs) and by regulatory authorities. Readers are advised to refer to these documents before preparing a regulatory submission based on the SDTM.

This document is a successor to what was known in prior versions as the CDISC Submission Data Standards or Submission Domain Models. Whereas SDTM v1.0 was designated as the first implementation-ready version for clinical studies involving human drug products, improvements and enhancements have been incorporated in subsequent versions to support a broader range of regulated products, including the needs of non-clinical animal toxicity studies. Efforts will continue to further evaluate the model for human and animal studies involving other regulated products including food additives; therapeutic biologics; blood derivatives; vaccines; cellular, tissue, and gene therapy; and devices. Implementation guides for applying the model to each type of data and guidance on controlled terminology will be published separately.

The SDTM has been designed for backward compatibility; datasets prepared with prior versions should be compatible with v1.7. In most cases, this means that later versions may add new variables or correct textual errors, but do not eliminate variables or structures incorporated in prior versions. There are, however, isolated instances where some older variables may be deprecated in favor of newer, more functional variables. SDTM v1.7 does not identify any proposed deprecated variables, as there are no variables to be deprecated at this time.

The following new sections and tables have been added:

• Table 4.1.5.1, Device-Subject Relationships Dataset
• Section 5, Study References
  • Section 5.1, Datasets for Study References
    • Section 5.1.1, Device Identifiers Dataset
      • Table 5.1.1.1, Device Identifiers Dataset
    • Section 5.1.2, Non-Host Organism Identifiers Dataset
      • Table 5.1.2.1, Non-Host OI Dataset

New variables have been added to the following sections:

• Section 2.2, The General Observation Classes
  • Table 2.2.1.1, Interventions—Topic and Qualifier Variables
  • Table 2.2.6.1, Subject Demographics Domain Variables
  • Table 2.2.7.1, Comments Domain Variables
  • Table 2.2.12.1, Domain-Specific Variables for General Observation Class Domains

An additional column, Role, has been added to all tables in the SDTM.

The SDTM provides a general framework for describing the organization of information collected during human and animal studies and submitted to regulatory authorities. The model is built around the concept of observations, which consist of discrete pieces of information collected during a study. Observations normally correspond to rows in a dataset. A collection of observations on a particular topic is considered a domain. For example, "Subject 101 had an adverse event of mild nausea starting on Study Day 6" is an observation belonging to the Adverse Events domain in a clinical trial.

Each observation can be described by a series of named variables. Each variable, which normally corresponds to a column in a dataset, can be classified according to its role. A "role" describes the type of information conveyed by the variable about each distinct observation and how it can be used. SDTM variables can be classified into 5 major roles:

• Identifier variables, such as those that identify the study, the subject (individual human or animal or group of individuals) involved in the study, the domain, and the sequence number of the record;
• Topic variables, which specify the focus of the observation (e.g., the name of a lab test);
• Timing variables, which describe the timing of an observation (e.g., start date, end date);
• Qualifier variables, which include additional illustrative text or numeric values that describe the results or additional traits of the observation (e.g., units, descriptive adjectives); and
• Rule variables, which express an algorithm or executable method to define start, end, or looping conditions in the Trial Design model.

Domain-specific variables, a concept introduced in SDTM v1.5, are for use in a limited number of designated domains and will be identified in the appropriate implementation guide. The variable names include the specific domain prefix. Section 2.2.12, Domain-Specific Variables for the General Observation Classes, lists the proposed domain-specific variables.

The set of Qualifier variables can be further categorized into 5 sub-classes:

• Grouping Qualifiers used to group together a collection of observations within the same domain (e.g., --CAT and --SCAT);
• Result Qualifiers, which describe the specific results associated with the topic variable in a Findings dataset and which answer the question raised by the topic variable (e.g., --ORRES, --STRESC, --STRESN);
• Synonym Qualifiers specifying an alternative name for a particular variable in an observation (e.g., --MODIFY and --DECOD, which are equivalent terms for a --TRT or --TERM Topic variable; --TEST for --TESTCD);
• Record Qualifiers, which define additional attributes of the observation record as a whole, rather than describing a particular variable within a record (e.g., --REASND, AESLIFE, and all other Serious Adverse Event flag variables in the AE domain; AGE, SEX, and RACE in the Demographics domain; --REASND, --POS, --LOC, --SPEC, and --NAM in a Findings domain); and
• Variable Qualifiers used to further modify or describe a specific variable within an observation and which are only meaningful in the context of the variable they qualify (e.g., --ORRESU, --ORNRHI, and --ORNRLO, all of which are Variable Qualifiers of --ORRES; --DOSU, which is a Variable Qualifier of --DOSE).

For example, in the observation "Subject 101 had mild nausea starting on Study Day 6," the Topic variable value is the term for the adverse event, "NAUSEA". The Identifier variable is the subject identifier, "101". The Timing variable is the study day of the start of the event, which captures the information "starting on Study Day 6", whereas an example of a Record Qualifier is the severity, the value for which is "MILD". Additional Timing and Qualifier variables could be included to provide the necessary detail to adequately describe an observation.

Most of the data collected in a study is about the subjects who are enrolled in the study. Sometimes, however, data is collected about other persons (Associated Persons, AP) who can be associated with the study, a particular study subject, or a device used in the study. AP may or may not have a familial relationship to a study subject.

Observations about study subjects are normally collected for all subjects in a series of domains. A "domain" is defined as a collection of logically related observations with a common topic. The logic of the relationship may pertain to the scientific subject matter of the data or to its role in the trial. Each domain dataset is distinguished by a unique, 2-character code that should be used consistently throughout the submission. This code, which is stored in the SDTM variable named DOMAIN, is used in 4 ways: as the dataset name, as the value of the DOMAIN variable in that dataset, as a prefix for most variable names in that dataset, and as a value in the RDOMAIN variable in relationship tables.

All datasets are structured as flat files with rows representing observations and columns representing variables; each dataset is described by metadata definitions that provide information about the variables used in the dataset. The Define.XML specification provides additional information.

The SDTM describes the name, label, role, and type for the standard variables. Note that the SDTM type specified in this document is either character or numeric, as these are the only types supported by SAS v.5 transport files. Define.XML provides more descriptive data types (e.g., integer, float, date, datetime); see the Define.XML specification for information about how to represent SDTM types using Define.XML data types.

A sponsor may drop certain variables (those defined as permissible in the relevant implementation guide) from the dataset and the corresponding descriptions from the Define.XML (i.e., the applicable "ItemRef" must be removed from the "ItemGroupDef" representing the dataset, as long as no data were collected for these variables). New sponsor-defined variables must not be added, and existing variables must not be renamed or modified for novel usage. Sponsors should consult the appropriate implementation guide; the implementation guides specifically describe which variables are required, expected, or permissible to use in specific domains based on the general observation classes.

The majority of observations collected during a study can be divided among 3 general observation classes: Interventions, Events, or Findings.

• The Interventions Observation Class, described in Table 2.2.1.1, 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"), coincident with the study assessment period (e.g., "concomitant medications"), or other substances self-administered by the subject (e.g., "alcohol", "tobacco", or "caffeine").
• The Events Observation Class, described in Table 2.2.2.1, 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 Observation Class, described in Table 2.2.3.1, captures observations resulting from planned evaluations to address specific tests or questions such as laboratory tests, ECG testing, and questions listed on questionnaires. The Findings class also includes a sub-type, "Findings About", which is used to record findings related to observations in the Interventions or Events class.

Datasets based on any of the general observation classes share a set of common Identifier and Timing variables. The set of Identifiers for All Classes variables used is described in Table 2.2.4.1. The set of Timing Variables for All Classes variables that should be used for all 3 general observation classes is included in Table 2.2.5.1. As a general rule, any valid Identifier or Timing variable is permissible for use in any submission dataset based on a general observation class.

In the tables in this section, the presence of two hyphens before the variable name (e.g., --TRT) is used to indicate the required use of a prefix based on the 2-character domain code. The domain code is used as a variable prefix to minimize the risk of difficulty when merging or joining domains for reporting purposes.

In addition to the 3 general observation classes, a submission will generally include a set of other special-purpose datasets of specific standardized structures to represent additional important information. For example:

• A Demographics special-purpose domain is included with human and animal studies (see Demographics).
• Other special-purpose domains may be included, such as Comments, Subject Elements, Subject Visits, Subject Disease Milestones, Subject Repro Stages
• Domain-Specific Variables for the General Observation Classes.
• Submissions may include datasets to describe the design of a trial (see Section 3, Trial Design Datasets).
• Submissions may include datasets to represent the relationships between datasets and records (see Section 4, Representing Relationships Among Datasets and Records).
• Submissions may include datasets illustrating how to apply the model fundamentals to associated persons (see Section 6, Applying Model Fundamentals to Associated Persons).

The SDTM is the foundation for many implementations. Examples include the SDTM Implementation Guide for Human Clinical Trials and the SEND (Standard for the Exchange of Nonclinical Data) Implementation Guide, available on the CDISC website: https://www.cdisc.org/standards. Not all variables described in the tables in this document (SDTM tables) are appropriate for all implementations. Refer to the implementation guides for specific information on any restrictions.

Table 2.2.1.1 Interventions—Topic and Qualifier Variables—One Record per Constant-Dosing Interval or Intervention Episode

Table 2.2.2.1 Events—Topic and Qualifier Variables—One Record per Event

Table 2.2.3.1 Findings—Topic and Qualifier Variables—One Record per Finding

Findings About Events or Interventions utilizes the Findings General Observation Class variables with the addition of the --OBJ variable, as described in the following table. Note that the --OBJ variable must only be used in Findings About Events or Interventions.

Table 2.2.3.1.1 Findings About—Additional Qualifiers

All of the following identifier variables are available for use in any domain based on one of the 3 general observation classes. STUDYID, DOMAIN, and --SEQ are required in all domains based on one of the 3 general observation classes. Each general class domain must also include at least one of the following subject identifiers: USUBJID, APID, SPDEVID, or POOLID.

All identifier variables are allowed for all implementation guides.

Table 2.2.4.1 All Observation Classes—Identifiers

The following timing variables are available for use in any domain based on one of the 3 general observation classes, except where restricted in the assumptions for the standard domain models in the implementation guides. See Sections 2.2.6-2.2.11 for additional guidance relating to special-purpose domains.

Table 2.2.5.1 All Observation Classes—Timing Variables

Each study must include 1 standardized set of observations in a specific structure; this is the Demographics domain described in Table 2.2.6.1. Demographics is the parent domain for all other observations for subjects and should be identified with the domain code of "DM". The DM domain describes the essential characteristics of the study subjects, and is used by reviewers for selecting sub-sets of subjects for analysis. The DM domain, as with other datasets, includes Identifiers, a Topic variable, Timing variables, and Qualifiers. See the respective implementation guides for further guidance regarding use of additional Identifier and Timing variables.

Table 2.2.6.1 Subject Demographics Domain Variables

Comments are collected during the conduct of many studies. These are normally supplied by a principal investigator, but might also be collected from other sources such as central reviewers. When collected, comments should be submitted in a single Comments domain, which is defined in Table 2.2.7.1.

See the implementation guides for further guidance regarding use of additional Identifier and Timing variables.

Table 2.2.7.1 Comments Domain Variables

Subject Elements describes the actual order of Elements that were traversed by the subject, together with the start date or start date and time and end date/time for each Element (see Table 2.2.8.1). Planned Elements are described in the Trial Design Model (see Section 3.1.1, Trial Elements). Because actual data does not always follow the plan, the SDTM allows for descriptions of an unplanned Element for subjects (SEUPDES).

See the implementation guides for further guidance regarding use of additional Identifier and Timing variables.

Table 2.2.8.1 Subject Elements—One Record per Actual Element per Subject

Subject Visits describes the actual start and end date/time for each visit of each individual subject (see Table 2.2.9.1). Planned trial visits are described in the Trial Design Model (see Section 3.1.3, Trial Visits). Because actual data does not always follow the plan, the SDTM allows for descriptions of unplanned visits for subjects (SVUPDES).

See the implementation guides for further guidance regarding use of additional Identifier and Timing variables.

Table 2.2.9.1 Subject Visits—One Record per Subject Visit, per Subject

Subject Disease Milestones (see Table 2.2.10.1) is designed to record the timing, for each subject, of Disease Milestones that have been defined in the Trial Disease Milestones (see Section 3.5, Trial Disease Milestones).

Table 2.2.10.1 Subject Disease Milestones—One Record per Disease Milestone, per Subject

Subject Repro Stages (not for use with human clinical trials; see Table 2.2.11.1) describes the actual order of Repro Stages experienced by the subject, together with the start date or start date and time and end date/time for each Repro Stage. The planned Repro Stages are described in the Trial Design Model (see Section 3.1.5, Trial Repro Stages). Because actual data does not always follow the plan, the SDTM allows for descriptions of an unplanned Repro Stage for subjects (SJUPDES).

Table 2.2.11.1 Subject Repro Stages—One Record per Actual Repro Stage per Subject

The concept of domain-specific variables was first introduced in SDTM v1.5. These variables are for use only in a specific domain and will be identified in the appropriate implementation guide. The variable names include the specific domain prefix. Table 2.2.12.1 lists the proposed domain-specific variables.

Table 2.2.12.1 Domain-Specific Variables for General Observation Class Domains

The Trial Design Model defines a standard structure for representing the planned sequence of activities and the treatment plan for the trial. The model provides a standard way to define the treatment groups and planned visits and assessments that will be experienced by trial subjects.

The model is built upon the concepts of Elements, Arms, Epochs, and Visits. The variables corresponding to these concepts are used in many domains. The implementation guides define specific details and examples for Trial Design.

Under the model, planned information is presented in a series of up to 6 tables:

• Trial Elements describes the Element code (unique for each Element), the Element description, and the rules for starting and ending an Element.
• Trial Arms describes each planned Arm in the trial. An Arm is an ordered sequence of Elements; and the same Element may occur more than once in a given Arm. In order to accommodate complex Trial Designs, this dataset allows for rules for branching from one Element to another when a choice is available, and a rule for transitions to allow a subject to skip ahead to another Element rather than proceed linearly.
• Trial Visits describes the planned order and number of visits in the study. In the case where visits vary for each Arm, there would be a separate record per Visit per Arm. Trial Visits also describes the allowable or planned values for VISIT, VISITNUM, and VISITDY in the trial (which are subsequently used as Timing Variables for the collected study data), and rules for starting and ending each visit. In most blinded trials, the timing of visits is the same for all subjects in all Arms.
• Trial Sets allows the submission of detailed information about planned groups of subjects that results as a combination of experimental factors of interest for a study (including experimental parameters, inherent characteristics, and sponsor-defined attributes). A Set may be a planned subdivision of a Trial Arm, or may comprise one or more Trial Arms. These datasets are essential to determining whether data comparisons are feasible across different studies.
• Trial Repro Stages describes the unique Repro Stages in a study, with Repro Stage description, code (short name) and rules for start and end. Note: Not for use with human clinical trials.
• Trial Repro Paths describes each planned Repro Path in a Repro study, with the ordered sequence of Repro Stages that comprise each Repro Path, as well as specification of Repro Phase and reference start day of the Repro Phase applicable to the Repro Stage within the Repro Path. Note: Not for use with human clinical trials.

Trial Elements describes the Element code (unique for each Element), the Element description, and the rules for starting and ending an Element (see Table 3.1.1.1).

Table 3.1.1.1 Trial Elements—One Record per Trial Element

Trial Arms describes each planned Arm in the trial (see Table 3.1.2.1). An Arm is an ordered sequence of Elements; the same Element may occur more than once in a given Arm. In order to accommodate complex trial designs, this dataset allows for rules for branching from one Element to another when a choice is available, and a rule for transitions to allow a subject to skip ahead to another Element rather than proceed linearly.

Note that the same Element may occur more than once within an Arm, but each occurrence would have a different value for TAETORD and EPOCH, and may have different values for TABRANCH and TATRANS.

Table 3.1.2.1 Trial Arms—One Record per Planned Element per Arm

Trial Visits describes the planned order and number of visits in the study. In the case where visits vary for each Arm, there would be a separate record per Visit per Arm. Trial Visits also describes the allowable or planned values for VISIT, VISITNUM, and VISITDY in the trial (which are subsequently used as Timing Variables for the collected study data), and rules for starting and ending each visit (see Table 3.1.3.1). In most blinded trials, the timing of visits is the same for all subjects in all Arms.

Table 3.1.3.1 Trial Visits—One Record per Planned Trial Visit

Trial Sets allows the submission of detailed information about planned groups of subjects that results as a combination of experimental factors of interest for a study (including experimental parameters, inherent characteristics, and sponsor-defined attributes; see Table 3.1.4.1). A Set may be a planned subdivision of a Trial Arm, or may comprise one or more Trial Arms. These datasets are essential to determining whether data comparisons are feasible across different studies.

Table 3.1.4.1 Trial Sets—One Record per Trial Set Parameter

Trial Repro Stages describes the unique Repro Stages in a study, with Repro Stage description, code (short name) and rules for start and end (see Table 3.1.5.1).

Table 3.1.5.1 Trial Repro Stages—One Record per Planned Repro Stage

Trial Repro Paths describes each planned Repro Path in a Repro study, with the ordered sequence of Repro Stages that comprise each Repro Path, as well as specification of Repro Phase and reference start day of the Repro Phase applicable to the Repro Stage within the Repro Path (see Table 3.1.6.1).

Table 3.1.6.1 Trial Repro Paths—One Record per Planned Repro Stage per Repro Path

Trial Inclusion/Exclusion contains one record for each of the inclusion and exclusion criteria for the trial.

Table 3.2.1 Trial Inclusion/Exclusion—One Record per Trial Inclusion or Exclusion Criterion

Trial Summary Information contains one record for each trial summary characteristic. Trial Summary is used to record basic information about the trial (e.g., trial phase, protocol title, design objectives).

Table 3.3.1 Trial Summary—One Record per Trial Summary Parameter

Trial Disease Assessments provides information on the planned protocol-specified disease assessment schedule (see Table 3.4.1). In oncology studies, compliance with the disease-assessment schedule is essential to reduce the risk of "assessment time bias". The TD domain makes possible an evaluation of assessment time bias from SDTM-based datasets by allowing comparison of the planned schedule of assessments against the actual occurrence of the efficacy assessments in order to determine the degree of compliance. TD has limited utility outside oncology (and indeed has limited utility within oncology studies). It was developed specifically with Response Evaluation Criteria in Solid Tumors (RECIST) in mind and, in particular, for studies with progression-free survival (PFS) endpoints where an assessment time bias analysis is appropriate.

Table 3.4.1 Trial Disease Assessments—One Record per Planned Constant Assessment Period

Trial Disease Milestones is used to describe observations or activities expected to occur in the course of the disease under study, the timing of which is of interest for the study.

Table 3.5.1 Trial Disease Milestones—One Record per Disease Milestone Type

There are many occasions when it is necessary or desirable to represent relationships among datasets or records. The SDTM identifies 8 distinct types of relationships:

• A relationship between a group of records for a given subject within the same dataset.
• A relationship between independent records (usually in separate datasets) for a subject, such as a concomitant medication taken to treat an adverse event.
• A relationship between 2 (or more) datasets where records of 1 (or more) dataset(s) are related to record(s) in another dataset (or datasets).
• A dependent relationship where data that cannot be represented by a standard variable within a general-observation class dataset record (or records) can be related back to that record.
• A dependent relationship between a comment in the Comments domain and a parent record (or records) in other datasets, such as a comment recorded in association with an adverse event.
• A relationship between a subject and a pool of subjects.
• A relationship between a subject and associated person(s). See Section 6.2, Associated Persons Relationships.
• A relationship between subjects in a study other than membership in a pool.

The implementation guides define specific details and examples for each of these relationships.

Table 4.1.1.1 RELREC Dataset

Table 4.1.2.1 SUPPQUAL Dataset

This dataset identifies individual subjects included in a pool of subjects for which a single observation record (pool level) is captured.

Table 4.1.3.1 POOLDEF Dataset

Some studies include subjects who are related to each other, and in some cases it is important to record those relationships. Studies in which pregnant women are treated and both the mother and her child(ren) are study subjects are the most common case in which relationships between subjects are collected. There are also studies of genetically based diseases where subjects who are related to each other are enrolled, and the relationships between subjects are recorded.

Table 4.1.4.1 RELSUB Dataset

The Device-Subject Relationships (DR) domain is a special-purpose domain that links each subject to the associated devices. Information in this domain may have been collected and submitted in other domains (e.g., Device Exposure, Device Tracking and Disposition, Device Events). This domain, however, provides a single, consistent location to find the relationship between a subject and a device, regardless of the device or the domain in which subject-related data may have been collected or submitted.

Table 4.1.5.1 Device-Subject Relationships Dataset

There are occasions when it is necessary to establish study-specific identifiers that will be used in subject data. Two such situations have been identified thus far:

• Identifiers for devices
• Identifiers for non-host organisms

The identity of a device is established by means of a number of parameters, then assigned an identifier. The parameters used for identification of a device depend on the kind of device and the needs of the study to distinguish among devices (see Table 5.1.1.1).

Table 5.1.1.1 Device Identifiers Dataset

The identity of a non-host organism is established by means of a number of taxa (categories used to classify living things), then assigned an identifier. The taxa used for identification of a non-host organism depend on the kind of organism and the needs of the study to distinguish among organisms.

Table 5.1.2.1 Non-Host Organism Identifiers Dataset

Associated Persons (AP) are persons other than study subjects who can be associated with a study, a particular study subject, or a device used in the study. AP domains are created using SDTM variables, with the application of specific AP rules, including:

• Implementers creating AP domains will follow the AP assumptions for the Identifier variables.
• AP will be the prefix for the domain and dataset name, and will identify the dataset as AP data.
• APID will be required in all AP datasets, and will identify records in a data warehouse as AP data.

The SDTM AP Implementation Guide (SDTMIG-AP) provides implementation rules, advice, and examples. Unless an exception is described in the SDTMIG-AP, all other general assumptions about SDTM and SDTMIG variables and domains apply to AP data.

Table 6.1.1.1 Associated Persons Data—Identifier Variables

To justify collection of AP data, some sort of a relationship is necessary between the AP and a study, a subject, or a device. However, a single value in SREL is inadequate to describe relationships to multiple subjects or devices and/or multiple relationships to a single subject or device. In such cases, the value MULTIPLE should appear in SREL. MULTIPLE may also appear in RSUBJID to describe relationships with multiple subjects. When other SDTM variables are populated with MULTIPLE, the multiple values are stored in Supplemental Qualifiers.

However, this approach has been found to be an indirect and cumbersome way to handle multiple AP-subject relationships. In addition, when there is AP data in multiple domains, the Supplemental Qualifier approach would require the same set of Supplemental Qualifiers to be repeated for each domain. The APRELSUB dataset, which parallels the structure of the RELSUB dataset, was created as a more efficient and simpler way to record these multiple relationships. The APRELSUB dataset is required for studies in which SREL values of MULTIPLE appear, but would not be needed if each AP has only one relationship to a study, a subject, or a device.

Table 6.2.1 APRELSUB Dataset

The SDTM has been designed to accommodate the broadest range of human and animal study data in a standardized manner. This document describes the basic concepts and general structure of the model. Individual implementation guides have been created to provide specific recommendations for numerous domains of data commonly collected in human, animal, and medical device studies, identifying which variables from a general observation class may apply. These implementation guides also describe basic assumptions and business rules, and provide numerous examples for mapping data to the standard format. Sponsor wishing to submit data in the standard formats should first consult the implementation guides before preparing a regulatory submission based on the SDTM. In addition to the implementation guides, multiple indication-specific therapeutic area user guides (TAUGs) provide examples and implementation advice for various therapeutic areas. The following implementation guides have been published by CDISC:

• The Study Data Tabulation Model Implementation Guide for Human Clinical Trials (SDTMIG)
• The Standard for Exchange of Non-Clinical Data Implementation Guide (SENDIG)
• The Study Data Tabulation Model Implementation Guide for Medical Devices (SDTMIG-MD)
• The Study Data Tabulation Model Associated Persons Implementation Guide (SDTMIG-AP)
• The Study Data Tabulation Model Pharmacogenomics/Genetics (SDTMIG-PGx)
• The Standard for Exchange of Non-Clinical Data Implementation Guide-Developmental and Reproductive Toxicology (SENDIG-DART)

Added the Role column to the Trial Design Datasets and Relationship Datasets.

Clarified the roles for the Special Purpose Datasets.

Variable Additions:

• Table 2.2.1.1 Interventions—Topic and Qualifier Variables
  • --RSDISC - Reason for Treatment Discontinuation
• Table 2.2.6.1 Subject Demographics Domain Variables
  • ARMNRS - Reason Arm and/or Actual Arm is Null
  • ACTARMUD - Description of Unplanned Actual Arm
• Table 2.2.7.1 Comments Domain Variables
  • COEVALID - Evaluator Identifier
  • CODY - Study Day of Comment
• Table 2.2.12.1 Domain-Specific Variables for General Observation Class Domains
  • MHEVDTYP - Medical History Event Date Type
  • MSAGENT - Agent Name
  • MSCONC - Agent Concentration
  • MSCONCU - Agent Concentration Units

Dataset Additions:

• Table 4.1.5.1 Device-Subject Relationships Dataset
• Table 5.1.1.1 Device Identifiers Dataset
• Table 5.1.2.1 Non-Host Organism Identifiers Dataset

CDISC Patent Disclaimers

It is possible that implementation of and compliance with this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any claim or of any patent rights in connection therewith. CDISC, including the CDISC Board of Directors, shall not be responsible for identifying patent claims for which a license may be required in order to implement this standard or for conducting inquiries into the legal validity or scope of those patents or patent claims that are brought to its attention.

Representations and Warranties

"CDISC grants open public use of this User Guide (or Final Standards) under CDISC's copyright."

Each Participant in the development of this standard shall be deemed to represent, warrant, and covenant, at the time of a Contribution by such Participant (or by its Representative), that to the best of its knowledge and ability: (a) it holds or has the right to grant all relevant licenses to any of its Contributions in all jurisdictions or territories in which it holds relevant intellectual property rights; (b) there are no limits to the Participant's ability to make the grants, acknowledgments, and agreements herein; and (c) the Contribution does not subject any Contribution, Draft Standard, Final Standard, or implementations thereof, in whole or in part, to licensing obligations with additional restrictions or requirements inconsistent with those set forth in this Policy, or that would require any such Contribution, Final Standard, or implementation, in whole or in part, to be either: (i) disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works (other than as set forth in Section 4.2 of the CDISC Intellectual Property Policy ("the Policy")); or (iii) distributed at no charge, except as set forth in Sections 3, 5.1, and 4.2 of the Policy. If a Participant has knowledge that a Contribution made by any Participant or any other party may subject any Contribution, Draft Standard, Final Standard, or implementation, in whole or in part, to one or more of the licensing obligations listed in Section 9.3, such Participant shall give prompt notice of the same to the CDISC President who shall promptly notify all Participants.

No Other Warranties/Disclaimers. ALL PARTICIPANTS ACKNOWLEDGE THAT, EXCEPT AS PROVIDED UNDER SECTION 9.3 OF THE CDISC INTELLECTUAL PROPERTY POLICY, ALL DRAFT STANDARDS AND FINAL STANDARDS, AND ALL CONTRIBUTIONS TO FINAL STANDARDS AND DRAFT STANDARDS, ARE PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, AND THE PARTICIPANTS, REPRESENTATIVES, THE CDISC PRESIDENT, THE CDISC BOARD OF DIRECTORS, AND CDISC EXPRESSLY DISCLAIM ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR OR INTENDED PURPOSE, OR ANY OTHER WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, FINAL STANDARDS OR DRAFT STANDARDS, OR CONTRIBUTION.

Limitation of Liability

IN NO EVENT WILL CDISC OR ANY OF ITS CONSTITUENT PARTS (INCLUDING, BUT NOT LIMITED TO, THE CDISC BOARD OF DIRECTORS, THE CDISC PRESIDENT, CDISC STAFF, AND CDISC MEMBERS) BE LIABLE TO ANY OTHER PERSON OR ENTITY FOR ANY LOSS OF PROFITS, LOSS OF USE, DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, OR SPECIAL DAMAGES, WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS POLICY OR ANY RELATED AGREEMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Note: The CDISC Intellectual Property Policy can be found at: cdisc_policy_003_intellectual_property_v201408.pdf.