| Num | Field or Variable | Guidance |
|---|
| 1 | --CAT, --SCAT | - Values Categories and subcategories are determined per protocol design and values are generally not entered on the via CRF by sites.
- Implementers may prepopulate : these site personnel
- individuals involved in data collection understand what data should be recorded on the CRF.
Implementers may also prepopulate - Pre-populate 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 tabulation dataset- Populate values directly in the tabulation dataset during dataset creation.
| | 2 | --PERF, --STAT, --REASND | - --PERF defines - variables to record whether an assessment has been performed/collected. --REASND is used to collect a reason why an assessment was not done.
- --PERF has the Question Text "[Were any/Was the] [--TEST/ topic] [measurement(s)/test(s) /examinations (s)/specimen(s) /sample(s) ] [performed/collected]?" are intended to assist in the cleaning of data and in confirming that there are no missing values.
- --PERF may be used at the page, panel, or question level.
- --PERF may be used during the creation of tabulaton datasets to derive a value into the SDTM variable --STAT. The implementer can use a combination of --CAT, --SCAT, with the --TESTCD= "--ALL" and --TEST= "<Name of the CRF module>" to represent what tests were not performed.
- Applicants must decide how to model each test not performed (e.g., to denote that all tests were not performed using TESTCD = "–ALL").
- --STAT has the Question Text "Was the [--TEST] not [completed/answered/done/assessed/evaluated]?; Indicate if (the [--TEST] was) not [answered/assessed/done/evaluated/performed]." This is intended to be used to collect a simple "NOT DONE" check box at the page, panel, or question level.
- --REASND is used with SDTM variable --STAT only. The value NOT DONE in --STAT indicates that the findings test was not performed.
| | 3 | --SPID | - --SPID may be populated by the applicant'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 applicant's data collection system.
| | 4 | Date and Time | - CDASH variables (--DAT, --TIM) are used in Findings domains to collect the date or date and time that the test was done or performed. The SDTM --DTC variable contains either a date or date and time when a specimen is collected or the start date or start date and time when a specimen is collected over time.
- Collecting the time is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail.
- Implementers must not use these elements to record a date that is the result of a test.
- The date of collection of a test may be derived from the date of visit. If so, a separate date of observation field is not required to be present on the CRF.
| | 5 | Horizontal (Denormalized) and Vertical Data Structures (Normalized) | - In metadata tables, many of the Findings class domains are presented in a normalized structure (1 record for each test) that is similar to the SDTM, even though many data management systems hold the data in a denormalized structure (1 variable for each test).
- When implementing CDASH in a denormalized structure, create variable names for the Findings --TEST and/or --TESTCD values. To do this, define the denormalized variable names using available CDISC Controlled Terminology for --TESTCD. Alternatively, CDASH variable names for data management systems allowing more than 8-character variable names can use CDASH variables using the following naming convention: <--TESTCD>_<-- SDTM variable name> where --TESTCD is the appropriate CT for the test code (e.g., DIABP_VSORRES, DIABP_VSLOC).
- In the horizontal (denormalized) setting, SDTM variables such as --PERF, --LOC , --STAT may be collected once for the whole horizontal record and applying the value to all of the observations on that record, or they can be collected per test using the CDASH variable such as <--TESTCD>_--PERF. When tabulation datasets are created, any variables collected for the entire horizontal record must be mapped to each vertical record (as appropriate).
- In the horizontal (denormalized) setting, an identifier (e.g., --GRPID) may be used to identify all --TESTCD collected on the same record. This facilitates transformation from the CDASH horizontal setting to the SDTM vertical setting and creation of RELRECs.
| | 6 | 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.
- --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 --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 tabulation datasets.
| | 7 | 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.
| | 8 | –ORRES, --RES, --DESC, and --RESOTH | - –ORRES, --RES, --DESC, and --RESOTH 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 tabulation dataset.
- --ORRES is used when the finding result is based on a single question and is mapped directly to a single row the tabulation dataset.
- It is recommended that:
- --ORRES 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, --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").
| | 9 | Root variables | - The Findings About Events and Intervention domains use the same root variables as the Findings domain, with the addition of the --OBJ variable.
| | 10 | Adding variables | - It is assumed that implementers will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., as required per protocol, business practice, or operating procedures) to Findings and Findings About domains.
|
|