You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Each metadata table within a given domain The following guidance should be used  Assumptions are also provided to further guide implementation


Observation Class


The following should be used


NumField or VariableGuidance
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 --SCATVariables 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.
3Date and Time Variables
  • CDASH date variables (e.g., --DAT, --STDAT,--ENDAT) are concatenated with CDASH time variables (e.g., --TIM, --STTIM, --ENTIM, if time is collected) into the appropriate SDTM --DTC variables (e.g., --DTC, --STDTC, --ENDTC) using ISO 8601 format.
  • Collecting the time of an event is only appropriate if it can be easily obtained and if there is a scientific reason, such as the need to know the order of events (e.g., the adverse event started after dosing). An example of this would be a study where the subject is confined to a phase 1 unit and under the direct care of the unit staff at the time that the event started or using time to tie together dosing and pharmacokinetic (PK) sample collection.

--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
  1. The CDASH variables used for coding are not data collection fields that will appear on the CRF itself. Sponsors will populate these through the coding process.
  2. When free-text event terms are entered, the location may be included in --TERM to facilitate coding and further clarify the event. This location information does not need to be removed from the verbatim term when creating SDTM submission datasets.
  3. The CDASH variables --LLT, --LLTCD, --PTCD, --HLT, --HLTCD, --HLGT, --HLGTCD, --SOC, and --SOCCD are only applicable to events coded in MedDRA.

Location (--LOC, --LAT, --DIR, --PORTOT)
  1. Location is collected when the sponsor needs to identify the specific anatomical location of the event.
  2. Implementers may collect the location information using a subset list of controlled terminology on the CRF. Location variables can be prepopulated as needed. There is currently some overlap across the LOC, LAT, and DIR variables for controlled terminology. While the overlap exists, ensure that this overlap for these variables is not part of database design. 






  • No labels