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:
- CDISC Controlled Terminology
- Conditional codelist
- PK unit codelist vs. normalized unit codelists
- External dictionaries, e.g., MedDRA, WHODrug Global, LOINC, DUNS, etc.
- Dataset and variable identifiers for data referential purpose, e.g., IDVAR, IDVARVAL, RDOMAIN
- Partially controlled:
- "UNPLAN" for SE.ETCD, otherwise not controlled
- "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:
| Variable | Value List | Remarks | |
|---|---|---|---|
| 1 | SMQzzSC | BROAD, NARROW | |
| 2 | SMQzzSCN | 1, 2 | This is a numerical representation of BROAD and NARROW in SMQzzSC. One can deduce the value meaning by pairing these two representations. However, to a machine, it will need a method to store the definition. |
| 3 | CRITyFL | Y or Y, N | Need clarification about this "or" notation |
| 4 | CRITyFN | 1 or 1, 0 | Same as SMQzzSCN, CRITyFN is the numerical representation of CRITyFL |
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:
| Variable | Described Value Domain | Value Domain in ODM Data Type(s) | Constrains | Rules | |
|---|---|---|---|---|---|
| 1 | --DTC | ISO 8601 datetime | datetime, date, time, partialDate, partialTime, partialDatetime, incompleteDatetime, intervalDatetime | ||
| 2 | --DTC | ISO 8601 duration | durationDatetime | ||
| 3 | --SEQ | Num | float | ||
| 4 | TDSTOFF | Num | integer | 0 or any positive integer | |
| 5 | RPRFDY | Num | integer | 0; 1 | |
| 6 | ECDOSE | Num | float | Any positive number | With a rule that a value can't be 0 |
Deduction
| # | CDISC Use Case | Is Represented as |
|---|---|---|
| 1 | TESTCD & TEST pairing | EVD with VM |
| 2 | CDASH CT as subset of SDTM CT | |
| 3 | Term mappings (e.g., RACEC to RACE) | Relationship, with a documented property of "how" |
| 4 | PK unit codelist vs. normalized unit codelists | Relationship, with a documented property of "how" |
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.
Questions
- Does ADaM's parameter VLM have any relevance here?
- 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 the BC can reference a codelist, which includes only the Height BC units. This subset will have an identifier such as a concept code.
Overview
Content Tools