- Created by Christine Connolly, last modified on Mar 01, 2023
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 16 Next »
The SDTM class for a data collection field is specified in the Observation Class column in the metadata table for the domain. General guidance for data collection fields by class are provided in the tables below and will be
The following should be used when the observation class for fields in a domain are Interventions.
1 | Data Collection Field(s) | Guidance |
---|---|---|
--YN variables | with the question text "Were there any interventions?" (e.g., “Were there any procedures?”, “Were there any concomitant medications?") are intended to assist in the cleaning of data and in confirming that there are no missing values. These variables are not included as part of the SDTM Intervention domains for submission and are annotated as NOT SUBMITTED on the CRF. | |
--CAT and/or --SCAT | are generally not entered on the CRF by the sites. Implementers may pre-populate and display these category values to help the site understand what data should be recorded on the CRF. Implementers may also prepopulate hidden variables with the values assigned within their operational database. Categories and subcategories are determined per protocol design, and could be populated during SDTM submission dataset creation. | |
Date and Time Variables |
| |
The CDASH variable -- REASND | is used with SDTM variable --STAT only. The value "NOT DONE" in --STAT indicates that the subject was not questioned about the intervention or that data were not collected; it does not mean that the subject had no interventions. | |
--SPID | variable may be populated by the sponsor's data collection system. If collected, it can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This field may be populated by the sponsor's data collection system. | |
Coding |
| |
Location (--LOC) and related variables (--LAT, --DIR, -- PORTOT) |
| |
Relative Timing Variables (see the SDTMIG for more information and details) |
|
The following should be used when the observation class for fields in a domain are Events.
Num | Field or Variable | Guidance |
---|---|---|
1 | --YN | Variables with the question text "Were there any <events>?" (e.g., “Were there any adverse events?”, “Were there any healthcare encounters?”) are intended to assist in the cleaning of data and in confirming there are no missing values. These questions can be added to any CRF in order to capture this information. |
2 | --CAT and/or --SCAT | Variables are generally not entered on the CRF by sites. Implementers may prepopulate and display these category values to help site personnel understand what data should be recorded on the CRF. Implementers may also prepopulate hidden variables with the values assigned within their operational database. Categories and subcategories are typically evident from the protocol design, and could be populated during SDTM dataset creation. |
3 | Date and Time Variables |
|
--COCCUR variable | (see Section 3.4, How to Collect New Data Collection Fields When No CDASHIG Field Has Been Defined, category 3) may be used when a specific event is solicited (preprinted) on the CRF and the CRF uses a sponsor-defined codelist. For example, a sponsor may combine the concepts of the CDASH OCCUR variable while also allowing for a "NOT DONE" response. Because the SDTM Controlled Terminology for --OCCUR only includes "N", "Y", and "UNKNOWN" responses, if the CDASH variable --OCCUR is used, the CRF would require a second question to indicate that the data were not collected. The CDASH variable --COCCUR is only used when events are prespecified. | |
--REASND | variable is used in conjunction with SDTM variable --STAT. The value "NOT DONE" in --STAT indicates that the subject was not questioned about the event or that data was not collected; it does not mean that the subject had no events. | |
The CDASH --SPID | variable may be populated by the sponsor's data collection system. If collected, it can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This field may be populated by the sponsor's data collection system | |
Coding |
| |
Location (--LOC, --LAT, --DIR, --PORTOT) |
|
The following should be used when the observation class for fields in a domain are Findings.
Num | Data Collection Field(s) | Guidance |
---|---|---|
--CAT and/or --SCAT | are generally not entered on the CRF by sites. Implementers may prepopulate and display these category values to help site personnel understand what data should be recorded on the CRF. Implementers may also prepopulate hidden variables with the values assigned within their operational database. Categories and subcategories that are not collected and are self-evident from the protocol design are populated during the creation of the SDTM submission dataset. | |
--PERF and --STAT | defines - variables to record whether an assessment has been performed/collected. --REASND is used to collect a reason why an assessment was not done.
| |
--SPID variable | may be populated by the sponsor's data collection system. If collected, it can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This field may be populated by the sponsor's data collection system. | |
Date and Time Variables |
| |
Horizontal (Denormalized) and Vertical Data Structures (Normalized) |
|
- Tests and Original Results
- The value in --TEST cannot be longer than 40 characters. The corresponding codelist value for the short test name (at most 8 characters) must also be populated in the SDTM variable --TESTCD.
- --TESTCD should be used to create a variable name and --TEST be used as the Prompt on the CRF. Both --TESTCD and --TEST are recommended for use in the operational database. See Section 5, Conformance to the CDASH Standard, for more details.
- CDASH variable --ORRES is used to collect test results or findings in the original units in character format.
- If the results are modified for coding, the --MODIFY variable contains any modified text.
- If normal or reference ranges are collected for results, the CDASH variables --ORNRLO and --ORNRHI and --NRIND are used.
- CDASH does not define the SDTM variable used to standardize the findings results (e.g., --STRESC, --STRESN) or to standardize the normal/reference ranges (--STNRLO,--STNRHI, --STNRC). The standardization of the original findings results and normal/reference ranges is expected to be performed during the creation of the SDTM submission datasets. Extensive discussion on the standardization of findings results is provided in the SDTMIG.
- Location Variables (--LOC, --LAT, --DIR, --PORTOT)
- These variables are used to collect the location of the test. The SDTM acknowledges that the results themselves may not be at the same location as the test. This is a known issue with the SDTM.
- Sponsors may collect the data using a subset list of controlled terminology on the CRF. --LOC could be a defaulted or hidden field on the CRF.
- CDASH uses the variables –ORRES, --RES, --DESC, and --RESOTH to collect results for the observation class findings. The variable pairs --RES/--DESC, and --RES/--RESOTH are often used when a finding result is collected using 2 CRF questions but is combined into a single row in the SDTM dataset. The variable --ORRES is used when the finding result is based on a single question, and is mapped directly to a single row in SDTM. CDASH recommends that:
- The --ORRES variable is used when the finding result is collected using a single question. The result should map directly to the SDTM variable --ORRES.
- --RES and --DESC are used when a question is asked to collect the finding result, with a follow-up question for a description of the finding. Typically, the question would be “Is the <condition> [normal/abnormal] or [absent/present]?", with a follow-up question such as “What is the abnormality?” or “What is the finding that was observed?” --RES is used to collect whether the finding is normal/abnormal or absent/present and --DESC is used to collect the description of the finding. Typically, this data is modeled in the SDTM as described in the Physical Examination (PE) domain:
- --ORRES result is normal/absent, or
- --ORRES is the actual abnormality/observed finding and the collected value abnormal/present are not represented.
- --RES and --RESOTH are used when a question is asked that allows the selection of a pre-specified finding, with a follow-up question to ask about the pre-specified response "OTHER". Typically, the question would be "What is the result?" with a set of prespecified responses, including the choice “OTHER” with the follow-up question “Specify, Other”. --RES is used to collect the finding with pre-specified responses, and --RESOTH is used to collect "Specify, Other". Typically, --RESOTH data is modeled in SDTM as --ORRES (instead of the response "OTHER").
- The Findings About Events and Intervention domains use the same root variables as the Findings domain, with the addition of the --OBJ variable. The CDASHIG metadata tables contain a generic FA domain.
It is assumed that implementers will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., therapeutic area-specific data elements; others as required per protocol, business practice, or operating procedures) to Findings and Findings About domains.
- No labels