This document describes the Study Data Tabulation Model (SDTM), which defines a standard structure for study data tabulations that are to be submitted as part of a product application to a regulatory authority such as the United States Food and Drug Administration (FDA). This document is based on material originally prepared by the Submissions Data Standards (SDS) Team of the Clinical Data Interchange Standards Consortium (CDISC), but is now maintained by the SDTM Governance Committee (SGC) of CDISC. This document, which supersedes all prior versions, includes numerous changes from the prior SDTM v1.5, which are described in Section 7.1, Changes from SDTM v1.5 to SDTM v1.6.

Data tabulation datasets are one of four ways to represent the human subject Case Report Tabulation (CRT) and equivalent animal data submitted to the FDA. CRTs are also submitted in the format of subject profiles, data listings, and analysis datasets. One benefit to industry of submitting data tabulation datasets that conform to the standard structure is that it minimizes the need to submit the same data in multiple formats.

The availability of standard submission data may provide many benefits to regulatory reviewers. Reviewers can now be trained in the principles of standardized datasets and the use of standard software tools, and thus be able to work with the data more effectively with less preparation time. Another benefit of the standardized datasets is that they can provide support for the FDA's efforts to develop a repository for all submitted studies and a suite of standard review tools to access, manipulate, and view the study data.

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

This document is a successor of what was known in prior versions as the CDISC Submission Data Standards or Submission Domain Models. While 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.6. 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.6 does not include any proposed deprecated variables.

The following new sections and tables have been added:

• Table 2.2.11: Subject Repro Stages
• Table 3.1.5: Trial Repro Stages
• Table 3.1.6: Trial Repro Paths

New variables have been added to the following sections:

• Table 2.2.3: Findings — Topic and Qualifier Variables
• Table 2.2.5: Timing Variables for All Classes
• Table 2.2.6: Demographics

An additional column, Format, has been added to Special Purpose Datasets (CO, DM, SE, SM, SV) and the Trial Design Datasets (TE and TD). The purpose of this column is to provide information on variables that use ISO 8601 and other formats in a structured, consistent way.

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 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 five 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 (such as the name of a lab test).
• Timing variables, which describe the timing of an observation (such as start date and end date).
• Qualifier variables, which include additional illustrative text, or numeric values that describe the results or additional traits of the observation (such as units or descriptive adjectives).
• 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. Table 2.2.12 lists the proposed domain-specific variables.

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

• Grouping Qualifiers are used to group together a collection of observations within the same domain. Examples include --CAT and --SCAT.
• Result Qualifiers describe the specific results associated with the topic variable in a Findings dataset. They answer the question raised by the topic variable. Result Qualifiers are --ORRES, --STRESC, and --STRESN.
• Synonym Qualifiers specify an alternative name for a particular variable in an observation. Examples include --MODIFY and --DECOD, which are equivalent terms for a --TRT or --TERM Topic variable, and --TEST for --TESTCD.
• Record Qualifiers define additional attributes of the observation record as a whole (rather than describing a particular variable within a record). Examples include --REASND, AESLIFE, and all other SAE flag variables in the AE domain; AGE, SEX, and RACE in the DM domain; and --REASND, --POS, --LOC, --SPEC, and --NAM in a Findings domain.
• Variable Qualifiers are used to further modify or describe a specific variable within an observation and are only meaningful in the context of the variable they qualify. Examples include --ORRESU, --ORNRHI, and --ORNRLO, all of which are Variable Qualifiers of --ORRES; and --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", while 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, APs) who can be associated with the study, a particular study subject, or a device used in the study. Associated Persons 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, two-character code that should be used consistently throughout the submission. This code, which is stored in the SDTM variable named DOMAIN, is used in four 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 metadata are described in a data definition document named "define" that is submitted with the data to regulatory authorities. See the Define-XML Specification, available at www.cdisc.org/define-xml. Define-XML specifies variable metadata attributes such as: name, label, data type, etc.

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 version 5 transport files. The Define-XML provides more descriptive data types (e.g. integer, float, date, datetime). Please see the Define-XML specification for information about how to represent SDTM types using Define-XML data types.

When creating submissions, a sponsor may drop certain variables (those defined as permissible in the 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, which 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 three general observation classes: Interventions, Events, or Findings:

• The Interventions class, described in Table 2.2.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 (such as alcohol, tobacco, or caffeine).
• The Events class, described in Table 2.2.2, 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, described in Table 2.2.3, captures the 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 Identifier variables used is described in Table 2.2.4. The set of Timing variables that should be used for all three general observation classes is included in Table 2.2.5. 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 two-character domain code. The domain code is used as a variable prefix to minimize the risk of difficulty when merging/joining domains for reporting purposes.

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

• A Demographics special-purpose domain is included with human and animal studies, described in Section 2.2.6, Demographics.
• Other special purpose domains such as Section 2.2.7, Comments, Section 2.2.8, Subject Elements, Section 2.2.9, Subject Visits, Section 2.2.10 Subject Disease Milestones, and Section 2.2.11, Subject Repro Stages
• Section 2.2.12, Domain-Specific Variables for the General Observation Class
• Datasets to describe the design of a trial, described in Section 3, The Trial Design Model
• Datasets to represent the relationships between datasets and records described in Section 4, Representing Relationships among Datasets and Records
• Applying model fundamentals to associated persons in Section 5, 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. Not all variables described in the tables in this document (SDTM tables) are appropriate for all implementations. Please refer to the implementation guides for specific information on any restrictions.

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

Table 2.2.2: Events — Topic and Qualifier Variables — One Record per Event

Table 2.2.3: 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, the --OBJ variable must only be used in Findings About Events or Interventions.

Table 2.2.3.1: Findings About — Additional Qualifiers

All of the following identifier variables are available for use in any domain based on one of the three general observation classes. STUDYID, DOMAIN, and --SEQ are required in all domains based on one of the three 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: All Observation Classes — Identifiers

All of the following timing variables are available for use in any domain based on one of the three general observation classes, except where restricted in implementation guide standard-domain-model assumptions.

All timing variables are allowed for all implementation guides.

Table 2.2.5: All Observation Classes — Timing Variables

Each study must include one standardized set of observations in a specific structure; this is the Demographics domain described in Table 2.2.6. Demographics is the parent domain for all other observations for subjects and should be identified with the domain code of "DM". The Demographics domain describes the essential characteristics of the study subjects, and is used by reviewers for selecting subsets of subjects for analysis. The Demographics domain, as with other datasets, includes Identifiers, a Topic variable, Timing variables, and Qualifiers. Since DM has a fixed structure, only certain variables may be added as appropriate. See the implementation guides for guidance on which additional variables can be added to this domain.

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

Please see Implementation Guide for further guidance regarding use of additional Identifier and Timing variables.

Table 2.2.7: Comments Domain Variables

The Subject Elements dataset describes the actual order of Elements that were traversed by the subject, together with the start date/time and end date/time for each Element. The planned Elements are described in Section 3.1.1, Trial Elements, of the Trial Design Model. Because actual data does not always follow the plan, the model allows for descriptions of an unplanned Element for subjects.

Please see the specific implementation guides for further guidance regarding use of additional Identifier and Timing variables.

Table 2.2.8: Subject Elements — One Record per Actual Element per Subject

* Optional additional qualifier variables are placed at the end because they are seldom used.

The Subject Visits dataset describes the actual start and end date/time for each visit of each individual subject. The planned trial visits are described in Section 3.1.3, Trial Visits, of the Trial Design Model. Because actual data does not always follow the plan, the model allows for descriptions of unplanned visits for subjects.

Please see the Implementation Guides for further guidance regarding use of additional Identifier and Timing variables.

Table 2.2.9: Subject Visits — One Record per Subject Visit, per Subject

* Optional additional Qualifier variables are placed at the end because they are seldom used.

The Subject Disease Milestones domain is designed to record the timing, for each subject, of Disease Milestones that have been defined in Section 3.5, Trial Disease Milestones.

Table 2.2.10: Subject Disease Milestones — One Record per Disease Milestone, per Subject

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

Table 2.2.11: Subject Repro Stages — One Record per Actual Repro Stage per Subject

* Optional additional qualifier variables are placed at the end because they are seldom used.

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 lists the proposed domain-specific variables.

Table 2.2.12: Domain-Specific Variables for General Observation Class Domains

The Trial Design Model defines a standard structure for representing the planned sequence of events 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 four tables:

• The Trial Elements dataset (TE) (Table 3.1.1) describes the Element code (unique for each Element), the Element description, and the rules for starting and ending an Element. A rule could be expressed as pseudo code or as executable code for determining transitions from one Element to another.
• The Trial Arms dataset (TA) (Table 3.1.2) describes each planned Arm in the trial. An Arm is described as 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.
• The Trial Visits dataset (TV) (Table 3.1.3) describes the planned order and number of visits in the study. In the case when visits vary for each Arm, there would be a separate record per Visit per Arm. It 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.
• The Trial Sets dataset (TX) (Table 3.1.4) allows the submission of detailed information about planned groups of subjects that result 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 consist of one or more Trial Arms. These datasets are essential to determine whether data comparisons are feasible across different studies.
• The Trial Repro Stages domain (TT) (Table 3.1.5) describes the unique Repro Stages in a study, with Repro Stage code, description, and rules for start and end. Note: Not for use with human clinical trials.
• The Trial Repro Paths domain (TP) (Table 3.1.6) 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.

Table 3.1.1: Trial Elements — One Record per Trial Element

Table 3.1.2: Trial Arms — One Record per Planned Element per Arm

Note: 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.3: Trial Visits — One Record per Planned Trial Visit

Table 3.1.4: Trial Sets — One Record per Trial Set Parameter

Table 3.1.5: Trial Repro Stages — One Record per Planned Repro Stage

Table 3.1.6: Trial Repro Paths — One Record per Planned Repro Stage per Repro Path

The Trial Inclusion Exclusion Domain (TI) contains one record for each of the inclusion and exclusion criteria for the trial.

Table 3.2: Trial Inclusion/Exclusion — One Record per Trial Inclusion or Exclusion Criterion

The Trial Summary Information Domain (TS) contains one record for each trial summary characteristic. Trial Summary is used to record basic information about the trial, such as trial phase, protocol title, and design objectives.

Table 3.3: Trial Summary — One Record per Trial Summary Parameter

The TD domain provides information on the planned protocol-specified disease assessment schedule. In oncology studies, good 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 a 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: Trial Disease Assessments — One Record per Planned Constant Assessment Period

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

Table 3.5: 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 eight 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 two (or more) datasets where records of one (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 5.2, Associated Person 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: RELREC Dataset

Table 4.1.2: 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: 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: RELSUB 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 Study Data Tabulation Model Associate Persons Implementation Guide (SDTMIG-AP) provides implementation rules and advice. Unless an exception is described in this implementation guide, all other general assumptions about SDTM and SDTMIG variables and domains apply to AP data.

Table 5.1.1: Associated Persons Data — Identifier Variables

Some sort of a relationship is necessary between an AP and a study, a subject, or a device to justify collection of data for an AP. However, in cases where an AP has relationships to multiple subjects or devices and/or multiple relationships to a single subject or device, a single value in SREL is inadequate to describe these multiple relationships. In those cases, the value MULTIPLE should appear in SREL. If an AP has relationships with multiple subjects, MULTIPLE may also appear in RSUBJID. When other SDTM variables are populated with MULTIPLE, the multiple values are stored in Supplemental Qualifiers. However, this was found to be an indirect and cumbersome way to handle multiple relationships of an AP to subject(s). In addition, if an AP had 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 5.2: 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 structures 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. Any sponsor wishing to submit data in the standard formats should first consult the implementation guides before preparing a regulatory submission based on the SDTM. The following implementation guides have been published by CDISC:

1. The Study Data Tabulation Model Implementation Guide for Human Clinical Trials (SDTMIG)
2. The Standard for Exchange of Non-Clinical Data Implementation Guide (SENDIG)
3. The Study Data Tabulation Model Implementation Guide for Medical Devices (SDTMIG-MD)
4. The Study Data Tabulation Model Associated Persons Implementation Guide (SDTMIG-AP)
5. The Study Data Tabulation Model Pharmacogenomics/Genetics (SDTMIG-PGx)

Variable, Dataset and Section Changes and Additions

Variable Changes:

• Table 2.2.2: Interventions – Topic and Qualifier Variables
  Changed the Roles:
  • --PSTRG – Pharmaceutical Strength from Variable Qualifier to Record Qualifier
  • --PSTRGU – Variable Qualifier of --PSTRG from Variable Qualifier to Variable Qualifier of --PSTRG

Variable Additions:

• Table 2.2.3: Findings – Topic and Qualifier Variables
  • --RESLOC – Result Location of Finding
• Table 2.2.5: Timing Variables for All Classes
  • RPHASE – Repro Phase
  • RPPLDY – Planned Repro Phase Day of Observation
  • RPPLSTDY – Planned Repro Phase Day of Obs Start
  • RPPLENDY – Planned Repro Phase Day of Obs End
  • --RPDY – Actual Repro Phase Day of Observation
  • --RPSTDY – Actual Repro Phase Day of Obs Start
  • --RPENDY – Actual Repro Phase Day of Obs End
• Table 2.2.6: Demographics
  • RPATHCD – Planned Repro Path Code

Dataset Additions:

• Table 2.2.11: Subject Repro Stages (new table)
• Table 3.1.5: Trial Repro Stages (new table)
• Table 3.1.6: Trial Repro Paths (new table)

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.