Inventory

CDASH

All CDASH CT codelists are a subset of an SDTM CT codelist. CDASHIG v2.1 metadata table contain these relevant columns & their description:

• Controlled Terminology Codelist Name: This column contains the Controlled Terminology (CT) codelist name, e.g., "LOC", that is associated with the field. The SDTMIG indicates that certain variables (e.g., dates) use ISO formats as CT. However, in CDASH these variables are generally not collected using the ISO CT; these variables are converted to the ISO Format when the SDTM-based submission datasets are created.
  
• Subset Controlled Terminology / CDASH Codelist Name: This column contains the CDISC Controlled Terminology or CDASH Subset Codelist name that may be used for that specific variable (e.g., EXDOSFRM).
  

CDASH Model and CDASHIG have data collection fields that are specialized for external dictionaries. Suffice to add, there is dedicated column in the metadata table for users to easily discern this property. Examples:

• --PTCD and AEPTCD for "MedDRA code for the Preferred Term"
• --LOINC for "LOINC Code"
• --ATC1 and CMATC1 for WHODrug's "ATC Level 1 Description"

SDTM

In general, SDTM variable's controlled terms can be categorized into these categories:

1. CDISC Controlled Terminology
2. Conditional codelist
3. PK unit codelist vs. normalized unit codelists
4. External dictionaries, e.g., MedDRA, WHODrug Global, LOINC, DUNS, etc.
5. Dataset and variable identifiers for data referential purpose, e.g., IDVAR, IDVARVAL, RDOMAIN
6. Partially controlled:
   1. "UNPLAN" for SE.ETCD, otherwise not controlled
   2. "Screen Failure" for DM.ACTARM, otherwise subject to study design

ADaM

Value List

Aside from the use of CDISC CT and external dictionaries, some ADaM variables have a value list. Here is a representative list:

Codetables

Codetables have sometimes referred to response codelist in casual conversations, although their utilization goes beyond just test & response. The following sections describe some of the representative use cases.

QRS Supplement to SDTMIG

These supplement publications illustrate detailed relationship among --CAT, --TEST, --ORRES, --STRSC, --STRESN for QRS using SDTM CT; and, the alignment to the SDTMIG QS, FT, and RS domains. Additional properties in other SDTMIG variables may occasionally be at play, e.g., --EVLINT.

Response codelist is also applicable. Coded ordinals are a good example, where responses may have a numerical value (code) & a label (decode).

Term Mappings

Two prime examples published onto the CDISC webiste are collapsing 1) RACEC (90+ terms) to RACE (7 terms), and 2) ETHNICC (70+ terms) to ETHNIC (4 terms).

TESTCD & TEST Pairing

Whether it is pairing TESTCD with TEST or PARMCD with PARM CT codelists, the idea is relating coded terms to their corresponding decode where they share the same concept. In other words, they have the same meaning with different textual representation.

Value Domains Driven by Data Types

Certain CDISC variables have prescribed value domains that hinges on data types or sub-types. Here is a list of representative sample:

Model

Basic Construct

Let Severity be a Conceptual Domain (CD), then the set {MILD, MODERATE, SEVERE} is a Value Domain (VD) for this CD. Similarly, {1, 2, 3} is another set of VD, in an numerical representation. These 2 VDs fall to the VD subclass called Enumerated Value Domain (EVD). To overlay semantic, each member, or Permissible Value (PV) of the VD may have a Value Meaning (VE). Therefore, when each PV from these 2 EVDs share the same VE, they are bound.

Let Representation of Dates & Times be a CD. ISO 8601 Datetime and ISO 8601 Duration are the associated DVDs. Another class of VD is Described Value Domain (DVD). DVDs do not have enumerated members. Instead, the PV is through descriptions (VM), as suggested in the name.

Let VD be a set of PV, therefore:

1. A VD may have these properties
   1. An Administrative record
   2. A definition
   3. A data type
   4. A relationship to another VD
   5. A unit of measure, especially quantitative results
   6. A Format template e.g., CDASH's dates, ADaM's SAS format, etc.
   7. A length descriptor, for character data type
2. A VD may be enumerated, described, or continuous
   
   1. Enumerated VD contains discrete values, e.g., {MILD, MODERATE, SEVERE}
   2. Described VD contains a description of what data values are permissible, e.g., LLT from MedDRA by MSSO
   3. Continuous VD whose PV may be free text, with or without any nomenclature.
3. A PV may belong to 1..n VD
   1. A Permissible Value may have a Value Meaning
      1. Representation of its value meaning is independent of, and shall not be constrained by, the representation of its corresponding value
   2. A Value Meaning may have 1:n representations, hence taking a unique form of PV
   3. For a Permissible Value to become a member of VD, use a start date
   4. To retire a Permissible Value from a VD, use an end date

Deduction

Questions

1. Does ADaM's parameter VLM have any relevance here?
2. Is EVS onboard with managing subsets? In other words, must subsets need to have a unique identifier?

   However, for the BC Height the valid units of measure may only include two units, cm and in . CDISC 360 requires the instantiation of a codelist subset so that th e BC can reference a codelist , which includes only the Height BC units . This subs et will have an identifier such as a concept code.

3. Do we treat different components of an external dictionary as separate described value domains? For example, MedDRA's LLT, HLGT, etc as separate DVD in the repository?
4. The use case of SDTM variables having partially controlled values is weird. Any good suggestions?
5. PV-to-PV relationship will be useful for VD with VD-to-VD relationship. Example: Mapping of RACEC to RACE, ADaM's variable pairs of numeric & text variables with values such as {0, 1} and {Y, N}. Does it make sense?