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

Compare with Current View Page History

Version 1 Next »

  1. The CDASHIG AEYN variable with the question text “Were any adverse events experienced?” is intended to assist in the cleaning of data and in confirming that there are no missing values. This CDASHIG variable is not included as part of the SDTMIG AE domain for submission. This question is annotated as "NOT SUBMITTED" on the CRF.
  2. Categories AECAT and AESCAT
    1. AECAT and AESCAT should not be redundant with the dictionary coding provided by AEDECOD and AESOC (i.e., they should provide a different means of defining or classifying AE records).
    2. AECAT and AESCAT are intended for categorizations that are defined in advance. For example, a sponsor may have a separate CRF page for AEs of special interest and then another page for all other AEs. In cases where a category of AEs of special interest resembles a part of the dictionary hierarchy (e.g., "CARDIAC EVENTS"), the categorization represented by AECAT and AESCAT may differ from the categorization derived from the coding dictionary.
  3. Presence or Absence of Events
    1. AEs are most often collected as free-text, spontaneously reported adverse events. There may be cases where the occurrences of specific adverse events are solicited, per protocol requirements. In that case, the prespecified adverse events would be listed on the CRF with a "Yes/No" question (AEOCCUR) asking about the occurrence of each.
    2. The CDASHIG variable AEOCCUR does not map directly to an SDTM variable. Because the SDTM AE domain is intended to hold only adverse events that actually happen, all values collected in AEOCCUR for pre-specified AEs should be submitted in a Findings About Adverse Events domain (FAAE), where FAORRES = the value of AEOCCUR where FATESTCD = "OCCUR". In addition, where AEOCCUR = "Y", there should be a corresponding record in the AE domain. 
    3. It is important to reiterate the distinction between adverse events and clinical events, especially if there are prespecified terms. In consulting with regulatory authorities, certain events (e.g., events associated with protocol endpoints) may simply be clinical events. (See Section 8.2.3, Clinical Events, for more details.)
  4. Coding 
    1. AEDECOD is the preferred term derived by the sponsor from the coding dictionary. It is a required SDTMIG variable and must have a value. It is expected that the reported term (AETERM) will be coded using a standard dictionary such as MedDRA. Sponsors are expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes.
    2. AEMODIFY is a permissible SDTMIG variable and should be included if the sponsor’s coding procedure permits modification of a verbatim term. The modified term is listed in AEMODIFY. The variable should be populated per the sponsor’s coding procedure.
    3. The CDASHIG elements AELLT, AELLTCD, AEPTCD, AEHLT, AEHLTCD, AEHLGT, AEHLGTCD, AEBDSYCD, AESOC, and AESOCCD are only applicable to events coded in MedDRA. These items are not expected for non-MedDRA coding.
  5. Relative Timing Variables
    1. The AEONGO field does not map directly to an SDTMIG variable but it may be used to derive a value into an SDTMIG relative timing variable such as AEENRF or AEENRTPT. When populating AEENRF, if the AEONGO field is checked, a value of "DURING", "AFTER", or "DURING/AFTER" may be derived, as is appropriate to the study. When populating AEENRTPT, if the AEONGO field is checked, the value of "ONGOING" may be derived. Note: AEENRTPT must refer to a time-point anchor as described in AEENTPT.
    2. Note that AEONGO is a special-use case of "Yes/No", where the question is usually presented as a single possible response of "Yes" when there is no applicable end date at the time of collection. In this case, if the box is checked and the end date is blank, the desired SDTMIG relative timing variable can be derived according to assumption 5a. If the box is not checked (AEONGO is NULL) and an end date is present, no SDTMIG relative timing variable would be derived. In some cases unique to AE, the ongoing status may be determined from AE Outcome. AEONGO is only used to derive an appropriate SDTMIG relative timing variable and should not be submitted on its own in the AE or SUPPAE dataset. The purpose of collecting this field is to help with data cleaning and monitoring; this field provides further confirmation that the end date was deliberately left blank. 
  6. CDASHIG Action Taken Variables
    1. CDASHIG variables AEACN, AECONTRT, AEACNDEV, AEACNOYN, and AEACNOTH are used to collect the action taken as the result of an AE.
    2. AEACN describes action taken with study treatment as a result of the event. It is expected that a response would be provided for this question for all AEs. If multiple treatments are administered, then corresponding variables should be created to capture the action taken for each treatment. 
    3. AEACNOTH describes Other Action(s) taken in response to an adverse event that are unrelated to study treatment dose changes or other non-study treatment given because of this adverse event. This field is usually collected as a free-text field (e.g., Treatment Unblinded, Primary Care Physician Notified). If possible/desired, the sponsor can create sponsor-defined controlled terminology. The CDASHIG variable AEACNOYN is used in conjunction with AEACNOTH to assist in the cleaning of data and in confirming that AEACNOTH is not missing. AEACNOYN is not included as part of the SDTMIG AE domain for submission and is annotated as "NOT SUBMITTED" on the CRF. The CDASHIG variable AEACNOYN should only be used on the AE CRF.
    4. AECONTRT indicates if any non-study treatments were received because of this adverse event. If "Yes" is answered for this question, any drugs used are recorded on the Concomitant Medications CRF and any procedures performed are recorded on the Procedure CRF. The CDASHIG variables CMAENO (on the CM CRF) or PRAENO (on the PR CRF) can be collected to identify the adverse event associated with this treatment by recording the appropriate AESPID. The RELREC dataset can be used to identify this relationship. 
    5. AEACNDEV describes action taken with respect to a device in a study, which may or may not be the device under study. This field is usually collected as a free-text field. If possible/desired, the sponsor can create sponsor-defined controlled terminology. FDA medical device reporting (MDR) guidelines (available at https://www.fda.gov/medicaldevices/) provide controlled terminology for reporting device problems.
  7. Serious Adverse Events 
    1. If details regarding serious adverse events are collected in the clinical database, then it is recommended that a separate "Yes/No" variable be defined for each SAE type (AESCAN, AESCONG, AESDISAB, AESDTH, AESHOSP, AESLIFE, AESOD, AESMIE). 
    2. Sponsors should consult with the regulatory agencies to which data will be submitted regarding the collection of this data (see, e.g., FDA study data technical conformance guidance, available at https://www.fda.gov/ForIndustry/DataStandards/). The serious categories Involves Cancer (AESCAN) and Occurred with Overdose (AESOD) are not part of the ICH definition of an SAE, but these categories are available for use in studies conducted under guidelines that existed prior to the FDA’s adoption of the ICH definition. 
  8. CDASHIG Variables AESEV, AETOXGR
    1. In studies using a standard toxicity scale (e.g., the US National Cancer Institute's Common Terminology Criteria for Adverse Events (CTCAE); available at https://ctep.cancer.gov/protocoldevelopment/), AETOXGR should be used instead of AESEV. In most cases, either AESEV or AETOXGR is populated, but not both. 
    2. There may be cases in which a sponsor may need to populate both variables. Whether populating either AESEV or AETOXGR or both, the sponsor is expected to provide the dictionary name and version or standard toxicity scale name and version used to map the terms utilizing Define-XML external codelist attributes.
  9. CDASHIG Variable DTHDAT
    1. The CDASH Model allows the date of death to be collected on any CRF deemed appropriate by the sponsor. Death date is mapped to other SDTMIG domains, as deemed appropriate by the sponsor (e.g., DM, DS).
    2. The death date should only be collected on 1 form.
  • No labels