Below is a sample of Description and CDISC Notes for variables found in SDTM v1.7, SDTMIG v3.3, SENDIG v3.1. Its purpose is to tease out variable properties that may be entangled in the original text. A property is either normative or informative. Normative properties are details must be followed for standards conformance purposes, whereas informative properties are descriptive details to further explain certain concepts. The primary goal is to inventory variable properties, there is no attempt to "clean up" text in each separated properties.
Observations:
- Near-Definition Text cannot always be deduced from original text
- Inconsistent use of modal verbs to convey varying concepts of conformance (see: RFC 2119: https://www.ietf.org/rfc/rfc2119.txt)
| Normative | Informative | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Original Text (Source) | Near-Definition Text | Value Domain: Codelist, Codelist Subset, Value List, External Dictionary | Data Format | Data Rule | Usage Rule | Manipulations: Transformation, Derivation, Imputation | Example Values | Implementation Notes | Reference |
| Is this a serious event? Valid values are "Y" and "N" (SDTMIG v3.3) | Is this a serious event? | Valid values are "Y" and "N" | |||||||
| The severity or intensity of the event. Examples: "MILD", "MODERATE", "SEVERE". (SDTMIG v3.3) | The severity or intensity of the event. | Examples: "MILD", "MODERATE", "SEVERE". | |||||||
| Term for the medical condition or event. Most likely preprinted on CRF. (SDTMIG v3.3) | Term for the medical condition or event. | Most likely preprinted on CRF. | |||||||
| Describes the reason clinical event data was not collected. Used in conjunction with CESTAT when value is "NOT DONE". (SDTMIG v3.3) | Describes the reason clinical event data was not collected. | Used in conjunction with CESTAT when value is "NOT DONE". | |||||||
| End date/time of the clinical event, represented in ISO 8601 character format. (SDTMIG v3.3) | End date/time of the clinical event | represented in ISO 8601 character format. | |||||||
| Describes the end of the event relative to the sponsor-defined reference period. The sponsor-defined reference period is a continuous period of time defined by a discrete starting point and a discrete ending point (represented by RFSTDTC and RFENDTC in Demographics). Not all values of the codelist are allowable for this variable. See Section 4.4.7, Use of Relative Timing Variables. (SDTMIG v3.3) | Describes the end of the event relative to the sponsor-defined reference period. | The sponsor-defined reference period is a continuous period of time defined by a discrete starting point and a discrete ending point (represented by RFSTDTC and RFENDTC in Demographics). | See Section 4.4.7, Use of Relative Timing Variables. | ||||||
Identifies the end of the event as being before or after the reference time point defined by variable HOENTPT. (SDTMIG v3.3) Not all values of the codelist are allowable for this variable. See Section 4.4.7, Use of Relative Timing Variables. (SDTMIG v3.3) | Identifies the end of the event as being before or after the reference time point defined by variable HOENTPT. | Not all values of the codelist are allowable for this variable. See Section 4.4.7, Use of Relative Timing Variables. | |||||||
| A value of "Y" indicates that this medical history event was pre-specified on the CRF. Values are null for spontaneously reported events (i.e., those collected as free-text verbatim terms). (SDTMIG v3.3) | A value of "Y"... Values are null for... | A value of "Y" indicates that this medical history event was pre-specified on the CRF. Values are null for spontaneously reported events (i.e., those collected as free-text verbatim terms). | |||||||
| Study day of medical history collection, measured as integer days. | Algorithm for calculations must be relative to the sponsor-defined RFSTDTC variable in Demographics. This formula should be consistent across the submission. | |||||||
Sequence number to ensure uniqueness of records within a dataset for a subject. May be any valid number (including decimals) and does not have to start at 1. (SDTMIG v3.3) | Sequence number to ensure uniqueness of records within a dataset for a subject. | any valid number (including decimals) | ensure uniqueness of records within a dataset | does not have to start at 1. | |||||
| Reference result for continuous measurements in original units. Should be collected only for continuous results. (SDTMIG v3.3) | Reference result for continuous measurements in original units. | Should be collected only for continuous results. | |||||||
| Short name of the TEST in TUTEST. TUTESTCD cannot be longer than 8 characters nor can start with a number. TUTESTCD cannot contain characters other than letters, numbers, or underscores. Example: "TUMIDENT". See TU Assumption 3. (SDTMIG v3.3) | Short name of the TEST in TUTEST. | TUTESTCD cannot be longer than 8 characters nor can start with a number. TUTESTCD cannot contain characters other than letters, numbers, or underscores. | Example: "TUMIDENT". | See TU Assumption 3. | |||||
| Controlled terminology for the name of disposition event or protocol milestone. Examples of protocol milestones: "INFORMED CONSENT OBTAINED", "RANDOMIZED". There are separate codelists used for DSDECOD where the choice depends on the value of DSCAT. Codelist "NCOMPLT" is used for disposition events and codelist "PROTMLST" is used for protocol milestones. The variable may be subject to controlled terminology for other events. (SDTMIG v3.3) | for name of disposition event or protocol milestone. | Controlled terminology... Codelist "NCOMPLT"... codelist "PROTMLST" | There are separate codelists used for DSDECOD where the choice depends on the value of DSCAT. Codelist "NCOMPLT" is used for disposition events and codelist "PROTMLST" is used for protocol milestones. | Examples of protocol milestones: "INFORMED CONSENT OBTAINED", "RANDOMIZED". | The variable may be subject to controlled terminology for other events. | ||||
| Indicator used to identify fasting status. Valid values include "Y", "N", "U" or null if not relevant. (SDTMIG v3.3) | Indicator used to identify fasting status. | Valid values include "Y", "N", "U" | or null if not relevant. | ||||||
| Indicator used to identify a baseline value. Should be "Y" or null. Note that VSBLFL is retained for backward compatibility. The authoritative baseline for statistical analysis is in an ADaM dataset. (SDTMIG v3.3) | Indicator used to identify a baseline value. | Should be "Y" or null. | The authoritative baseline for statistical analysis is in an ADaM dataset. | Note that VSBLFL is retained for backward compatibility. | |||||
| Optional group identifier, used to link together a block of related records within a subject in a domain. (SDTMIG v3.3) | group identifier, used to link together a block of related records within a subject in a domain. | Optional | |||||||
| May be derived (RFSTDTC - BRTHDTC), but BRTHDTC may not be available in all cases. Age may also be collected. (SENDIG v3.1) | but BRTHDTC may not be available in all cases. | May be derived (RFSTDTC - BRTHDTC) | Age may also be collected. | ||||||
| Used when the age is a range and the exact birthdate is not known. This variable is a character field for the purposes of defining age ranges, e.g., if the information available for the age of the subject is 6-8 and AGEU is WEEKS. Populate only when BRTHDTC or AGE is not specified. The format for AGETXT is “number-number” (e.g., 6-8). (SENDIG v3.1) | This variable is a character field for the purposes of defining age ranges | The format for AGETXT is “number-number” | Used when the age is a range and the exact birthdate is not known. | e.g., if the information available for the age of the subject is 6-8 and AGEU is WEEKS... (e.g., 6-8). | |||||
| ETCD (the companion to ELEMENT) is limited to 8 characters and does not have special character restrictions. (SENDIG v3.1) | ETCD (the companion to ELEMENT) | is limited to 8 characters and does not have special character restrictions. | |||||||
| Identification of a focus of study-specific interest on or within a subject or specimen as defined in the protocol for which a measurement, test, or examination was performed, such as a drug application site, e.g., “Injection site 1,” “Biopsy site 1,” “Treated site 1.” the value in this variable should have inherent semantic value. (SENDIG v3.1) | Identification of a focus of study-specific interest on or within a subject or specimen as defined in the protocol for which a measurement, test, or examination was performed, such as a drug application site, | e.g., “Injection site 1,” “Biopsy site 1,” “Treated site 1.” | the value in this variable should have inherent semantic value. | ||||||
| Start of the assessment interval relative to Time Point Reference (PPTPTREF) in ISO 8601 duration format. Example: When the area under the curve is calculated from 12 to 24 hours (PPTESTCD = AUCT1T2), the value would be PT12H. (SENDIG v3.1) | Start of the assessment interval relative to Time Point Reference (PPTPTREF) | in ISO 8601 duration format. | PT12H | Example: When the area under the curve is calculated from 12 to 24 hours (PPTESTCD = AUCT1T2), the value would be PT12H. | |||||
| Contains the result value for all findings, copied or derived from SCORRES in a standard format or standard units. SCSTRESC should store all results or findings in character format; if results are numeric, they should also be stored in numeric format in SCSTRESN. For example, if a test has results NONE, NEG, and NEGATIVE in SCORRES, these results effectively have the same meaning. In this case, they could be represented in standard format in SCSTRESC with a single term NEGATIVE. (SENDIG v3.1) | Contains the result value for all findings... SCSTRESC should store all results or findings in character format; | if results are numeric, they should also be stored in numeric format in SCSTRESN. | copied or derived from SCORRES in a standard format or standard units. | NEGATIVE | For example, if a test has results NONE, NEG, and NEGATIVE in SCORRES, these results effectively have the same meaning. In this case, they could be represented in standard format in SCSTRESC with a single term NEGATIVE. | ||||
| Defines the specific anatomical or biological region of a tissue, organ specimen, or the region from which the specimen was obtained, such as a section or part of what is defined in the TFSPEC variable. If the anatomical region is not included in the specimen description TFSPEC, it may be included in this variable. This field can be a combination of terms where needed. This field can be null if not applicable. Examples: CORTEX, MEDULLA, MUCOSA, SEROSA, ISLET, ZONA FASICULATA, ZONA RETICULARIS, CRANIAL, MEDIAN, ACCESSORY, SPINAL, LUMBAR, FRONTAL. (SENDIG v3.1) | Defines the specific anatomical or biological region of a tissue, organ specimen, or the region from which the specimen was obtained, | This field can be null if not applicable. | If the anatomical region is not included in the specimen description TFSPEC, it may be included in this variable. | Examples: CORTEX, MEDULLA, MUCOSA, SEROSA, ISLET, ZONA FASICULATA, ZONA RETICULARIS, CRANIAL, MEDIAN, ACCESSORY, SPINAL, LUMBAR, FRONTAL. | such as a section or part of what is defined in the TFSPEC variable... This field can be a combination of terms where needed. | ||||
| The reason the result should be excluded from all calculations. Used only when VSEXCLFL is Y. | The reason the result should be excluded from all calculations. | Used only when VSEXCLFL is Y. | |||||||
| Identifier for a single associated person, a group of associated persons, or a pool of associated persons. If APID identifies a pool, POOLDEF records must exist for each associated person. (See Pool Definition Dataset and Applying Model Fundamentals to Associated Persons). (SDTM v1.7) | Identifier for a single associated person, a group of associated persons, or a pool of associated persons. | If APID identifies a pool, POOLDEF records must exist for each associated person. | (See Pool Definition Dataset and Applying Model Fundamentals to Associated Persons). | ||||||
| Identifier used to uniquely identify a subject across all studies for all applications or submissions involving the product. Either USUBJID or POOLID must be populated. (SDTM v1.7) | Identifier used to uniquely identify a subject across all studies for all applications or submissions involving the product. | Either USUBJID or POOLID must be populated. | |||||||
| Identifier used to identify a pool of subjects. If POOLID is entered, POOLDEF records must exist for each subject in the pool and USUBJID must be null. Either USUBJID or POOLID must be populated. (SDTM v1.7) | Identifier used to identify a pool of subjects. | If POOLID is entered, POOLDEF records must exist for each subject in the pool and USUBJID must be null. Either USUBJID or POOLID must be populated. | |||||||
| Dosing information collected in text form. Examples: <1 per day, 200-400. Not populated when --DOSE is populated. (SDTM v1.7) | Dosing information collected in text form. | Not populated when --DOSE is populated. | Examples: <1 per day, 200-400. | ||||||
| Indicates whether the timing of a performed test or observation was unscheduled. If a test or observation was performed based upon a schedule defined in the protocol, this flag should be null. Expected values are Y or null. Not to be used with human clinical trials. This variable would not be needed when information on planned assessments is provided, such as when the Trial Visits (TV) and Subject Visits (SV) domains are used. (SDTM v1.7) | Indicates whether the timing of a performed test or observation was unscheduled. | Expected values are Y or null. | If a test or observation was performed based upon a schedule defined in the protocol, this flag should be null... Not to be used with human clinical trials. | This variable would not be needed when information on planned assessments is provided, such as when the Trial Visits (TV) and Subject Visits (SV) domains are used. | |||||
Evaluation interval associated with an observation, where the interval is not able to be represented in ISO 8601 format. Examples: LIFETIME, LAST NIGHT, RECENTLY, OVER THE LAST FEW WEEKS. (SDTM v1.7) | Evaluation interval associated with an observation | where the interval is not able to be represented in ISO 8601 format. | Examples: LIFETIME, LAST NIGHT, RECENTLY, OVER THE LAST FEW WEEKS. |
Overview
Content Tools
4 Comments
Deborah Rittenhouse
Diane, Is it a "property" when fields are associated/related with/to each other? For example, _ORRESU is not used without the corresponding _ORRES; in CDAS, _STTIM goes with _STDAT... Has there been any discussions on how to support machine-readable metadata about these associations/relatedness ?
Is this another topic, or is it an extension of this variable definitions discussion?
Anthony Chow
If you don't mind me chiming in Deborah Rittenhouse and Diane Wold, I would consider that a usage rule for --ORRESU, e.g., "Not used when ORRES is blank". This way, a test (or, computable rule) can be established.
Diane Wold
The rule, "Not used when ORRES is blank" would certainly be appropriate. There is additional meaning in the relationship between the two variables ORRES and ORRESU, that ORRESU is the unit in which ORRES is expressed when ORRES is a quantity. For conformance rule purposes, the additional meaning is not necessary. I'm not sure how much we want to capture in SHARE. In BRIDG terms, ORRES and ORRESU both map to PerformedObservationResult.value. When the ISO210090 datatype of the value is PQ (Physical Quantity), ORRES holds PQ.value while ORRESU holds PQ.unit. (For other datatypes, ORRESU doesn't come into play. ORRES always holds some component of the datatype of the value, but which datatype depends on circumstances.
Deborah Rittenhouse
Diane, I appreciate your in-depth knowledge of this. I don't know the details of the BRIDG and ISO rules. Thanks for the replies.