Clarifications

Text in an CDISC Note (in the SDTMIG) or Description (in the SDTM) may not be identical to the original publication due to differences in newlines, curly quotation marks, non-ASCII, and other special characters. This is done to better align with data exchange mechanisms (e.g., XML, CDISC ODM), as well as to avoid system compatibility issues. This is most notable in early PDF publications such as the SDTM, the SDTMIG, and the CDASHIG.

In the metadata repository's model, a parent-child relationship is used to convey how a dataset in an Implementation Guide references the same dataset in a Model. It is not used to represent data tabulation structure relationships such as that between a general observation class dataset and a Supplemental Qualifier or Associated Persons dataset. For example, the parent of the SDTMIG v3.2 DM dataset is the SDTM v1.4 DM dataset, but no parent-child relationship exists for the SDTMIG-AP APDM dataset in the metadata repository.

In rare cases, discrepancies in a published standard could cause information gaps in the metadata repository. For example, there are no codelist metadata associated to the SDTMIG-PGx v1.0 variables PBGENTYP, PFGENTYP, and SBGENTYP. This is because the GENTYP codelist cited for these variables in the Implementation Guide has not been published in CDISC Controlled Terminology.

Biomedical concepts and BRIDG will be available in future releases, at which point CDISC will re-evaluate the applications of BRIDG to CDISC foundational standards. BRIDG mappings for the CDASH v1.1 and the SDTMIG v3.1.2 are not included in the metadata repository.

When an enumerated value domain is relevant in an XML media type response (also known as value list), individual member terms will be in its own XML element . Value lists are most common in SDTMIG and ADaMIG products. For example, an excerpt from ADaMIG OCCDS v1.0' SMQzzC variable:

<?xml version="1.0" encoding="utf-8"?>
<cdiscLibrary>
    <analysisVariable>
        <ordinal>96</ordinal>
        <name>SMQzzSC</name>
        <label>SMQ zz Scope</label>
        ...
        <valueList>
            <value>BROAD</value>
            <value>NARROW</value>
        </valueList>
        ...

For the /mdr/products and /mdr/products/Terminology endpoints, the listing of Controlled Terminology packages is now within a JSON array named packages, instead of terminology. The purpose of this change is to stay consistent with the /mdr/ct/packages endpoint and its sub-paths. Example, showing packages on line #8 from /mdr/products/Terminology:

{
  "_links": {
    "self": {
      "href": "/mdr/products/Terminology",
      "title": "Product Group Terminology",
      "type": "CDISC Library Product Group"
    },
    "packages": [
      {
        "href": "/mdr/ct/packages/adamct-2014-09-26",
        "title": "ADaM Controlled Terminology Package 19 Effective 2014-09-26",
        "type": "Terminology"
      },
    ...
  }
}

This section contains API implementation information specific to certain media types.

text/csv (CSV)

1. When saving a response of text/csv media type, it is highly recommended to name the file with a .csv extension. This will allow software to properly parse the comma-delimited format.
2. The outputs use Unix style line endings, as well as newlines that could exist in the CDISC Notes/Description columns or other columns.
3. Values are qualified with double-quote, when commas are in a value.
4. Newlines and uneven quotes may be present in a few variable columns. For instance, newlines in Mapping Instructions for CDASH v1.1's --PERF under the Interventions class; uneven double-quotes in Implementation Notes for --RELNST.

Excel Workbook

• When saving a response of application/vnd.ms-excel media type, it is highly recommended to name the file with a .xlsx extension, instead of .xls. This will allow Office software to recognize the file is of Excel Workbook type.
• For SDTM, SDTMIG, and SENDIG, variable listing is sorted by Class's ordinal (not displayed), Dataset Name (lexicon order), and then Variable Order (numerical order).
• For CDASH, the order of SDTM Target is by lexicon, which may not match the original order in the publication.

Refer to Search (Copy) for details.

type is one of the scopes supported. Both "SDTM Dataset" and "SDTM Dataset Variable" are pre-aggregated for type. To limit search for just SDTM Dataset, use the negation operator, i.e., hyphen (0x2D):

/mdr/search/?q={searchExpression}type:SDTM Dataset -Variable

P41a is an interim, out-of-cycle publication, released on 2020-05-08 in conjunction with the Interim User Guide for COVID-19. All new and updated terms are subsumed in the P42 (2020-06-26) publication. P41a is not loaded into CDISC Library.

NEW Some codelists have "N/A" in the Extensible attribute. This is common in the Glossary and Protocol packages. For backward compatibility, CDISC Library maintains this as a Boolean attribute. The use of "N/A" is intentionally a close concept to "No". With those, the Data Standard Browser displays "No" in this case, while the API shows false for the extensible object in the JSON response.

In the CDASHIG v2.0 and v2.1, Data Scenario and Implementation Options are two independent columns. Implementation Options is not a concept in the CDASHIG v1.1. In order to offer one common API design for all CDASH products, these two columns are combined to become one single attribute. Example: This is an API response excerpt showing the two scenarios for domain DA:

"scenarios": [ 
  { 
    "href": "/mdr/cdashig/2-0/scenarios/DA.Denormalized", 
    "title": "DA - Denormalized - Implementation Options: Horizontal-Example", 
    "type": "CDASH Scenario" 
  }, 
  { 
    "href": "/mdr/cdashig/2-0/scenarios/DA.HorizontalGeneric", 
    "title": "DA - Implementation Options: Horizontal-Generic", 
    "type": "CDASH Scenario" 
  }, 
  ...

While the --OBJ in the SDTM is part of the Findings About subclass, in the CDASH Model v1.0, --OBJ is a variable that can be used in a Findings class domain. This is exemplified by the FAOBJ and SROBJ variables in the CDASHIG v2.0. The following query can be used to access the CDASH Model v1.0's --OBJ variable: /mdr/cdash/1-0/classes/Findings/fields/–OBJ

In CDASH Model v1.1, --OBJ, having re-aligned with SDTM, is a variable part of the Findings About subclass. It is accessible using this query: /mdr/cdash/1-1/classes/FindingsAbout/fields/--OBJ

CDASH products contain certain shorthand or generic references that are not transferable to the metadata repository. For example, in the CDASH Model v1.0, the Findings class variable --TEST has (--TEST) in the Controlled Terminology Codelist Name column. Similar shorthand reference also exists in the SDTMIG. In the SDTMIG v3.2, the variable QSTEST has (QSTEST) and variable QSTESTCD has (QSTESTCD) listed in the Controlled Terms, Codelist or Format column. No codelist metadata is available for this sort of generic codelist reference in the metadata repository.

There are variables with "Domain Specific" in the Observation Class column in all the CDASH Model publications. In the metadata repository, it is represented by a Boolean classifier. For example, this is a response excerpt for AEACNOYN from CDASH Model v1.0:

"ordinal": "1", 
"name": "AEACNOYN", 
"label": "Any Other Actions Taken", 
"definition": "An indication whether any other action(s) were taken in response to the adverse event that are unrelated to study treatment dose changes or other non-study treatments given because of this adverse event.", 
"domainSpecific": "true", 
...

The CDISC Controlled Terminology attached to the MITEST variable in CDASHIG v2.0 is MITS (C132262) instead of MITEST (C89973). MITEST is a SEND specific codelist.

The CDISC Controlled Terminology attached to the DDTEST variable in CDASHIG v2.0 has a C-code of C116107. This C-code was renamed from DDTEST to DTHDX in the P30 publication (2017-06-30).

For the SDTMIG and the SENDIG, the general observations class serves as a container for Interventions, Events, and Findings classes. Datasets belong to their respective general observation classes, such as Exposure (EX) to Interventions, Adverse Events (AE) to Events, and Laboratory Test Results (LB) to Findings. Therefore, no datasets will be listed under General Observations Class in the API response. In other words, when applying this JSON Path against the response from /mdr/sdtmig/{version}, it yields an empty result: $..classes[?(@.name=="General Observations")].datasets.

They are available in each of the three general observation classes. For example, an excerpt from the API response for this query /mdr/sdtmig/3-2/classes/Events:

"datasets": [ 
  { 
    "ordinal": "10", 
    "name": "AE", 
    ... 
  }, 
  { 
    "ordinal": "11", 
    "name": "CE", 
    "label": "Clinical Events", 
    ... 
  }, 
  { 
      "ordinal": "12", 
      "name": "DS", 
      "label": "Disposition", 
    ... 
  }, 
  ... 
]

In the Table 2.2.2 Events of SDTM v1.3, the variable --PRESP is said to be a Variable Qualifier of --TRT. However, --TRT is not valid in the Events class. Due to this typographical error, qualifiesVariables no longer appears in the response from this API request: /mdr/sdtm/1-3/classes/Events/variables/--PRESP.

For the ADaMIG, text such as "One record per subject" is used to describe an ADaM data structure concept. Actual structures used in submission datasets are defined based on study specific criteria. For example, users will get this as part of the API response when querying about the ADaMIG OCCDS v1.0:

"ordinal": "1", 
"name": "OCCDS", 
"label": "Occurrence Data Structure", 
"description": "One record per record in SDTM domain (optional: per coding path, per Analysis Period and/or Phase)", 
"class": "OCCDS", 
...