Versions Compared

Old Version 13

changes.mady.by.user Kathleen Mellars

Saved on

compared with

New Version 14

changes.mady.by.user Kathleen Mellars

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
  1. The 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 collection variable will not be represented in the tabulation dataset.
  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.
      Jira
      showSummaryfalse
      serverIssue Tracker (JIRA)
      serverId85506ce4-3cb3-3d91-85ee-f633aaaf4a45
      keyTOBA-710
      For example, an applicant 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 Adverse Experiences
    1. AEs are most often collected as free-text, spontaneously reported adverse events. There may be cases where the occurrences of specific adverse experiences are solicited, per protocol requirements. In that case, the prespecified adverse experiences would be listed on the CRF with a "Yes/No" question (AEOCCUR) asking about the occurrence of each.
    2. Collection variable AEOCCUR does not map directly to a tabulation variable. Because the tabulation AE domain is intended will only represent adverse experiences that actually happen, all values collected in AEOCCUR for pre-specified AEs should be represented in a tabulation 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. 
  4. Coding 
    1. AEDECOD is the preferred term derived by the applicant from the coding dictionary. It is a required tabulation variable and must have a value. It is expected that the reported term (AETERM) will be coded using a standard dictionary such as MedDRA. 
    2. AEMODIFY is a permissible tabulation variable and should be included if the applicant’s coding procedure permits modification of a verbatim term. The modified term is listed in AEMODIFY. The variable should be populated per the applicants’s coding procedure.
    3. The collection 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 a tabulation variable, but it may be used to derive a value into a tabulation 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 appropriate. When populating AEENRTPT, if the AEONGO field is checked, the value of "ONGOING" may be derived. AEENRTPT must refer to a time-point anchor as described in AEENTPT.
    2. 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.
      1. In this case, if the box is checked and the end date is blank, the desired tabulation relative timing variable can be derived according to assumption 5a.
      2. If the box is not checked (AEONGO is NULL) and an end date is present, no tabulation relative timing variable will be derived.
      3. In some cases, unique to AE, the ongoing status may be determined from AE Outcome. AEONGO is only used to derive an appropriate tabulation relative timing variable and should not be represented on its own in the AE or SUPPAE dataset. 
  6. Collection Action Taken Variables
    1. Collection 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 product as a result of the experience. It is expected that a response will be provided for this question for all AEs. When a study includes exposure to multiple products, then corresponding variables should be created to capture the action taken for each product. 
    3. AEACNOTH describes Other Action(s) taken in response to an adverse experience that are unrelated to study product exposure changes or treatment interventions given because of this adverse experience. This field is usually collected as a free-text field. If possible/desired, the applicant can create their own internal terminology.
      Jira
      showSummaryfalse
      serverIssue Tracker (JIRA)
      serverId85506ce4-3cb3-3d91-85ee-f633aaaf4a45
      keyTOBA-711
      The collection 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 tabulation AE domain for submission and is annotated as "NOT SUBMITTED" on the CRF. The collection variable AEACNOYN should only be used on the AE CRF.
    4. AECONTRT indicates if any interventions were received because of this adverse experience. 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 collection variables CMAENO (on the CM CRF) can be collected to identify the adverse experience associated with this intervention 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 applicant can create applicant-defined controlled terminology.
  7. Serious Adverse Experiences 
    1. If details regarding serious adverse events are collected, 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. Applicants should consult with the regulatory agencies regarding the collection of this data.
  8. Collection Variables AESEV, AETOXGR
    1. In studies using a standard toxicity scale, 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 an applicant may need to populate both variables. 
  9. Collection variable DTHDAT
    1. The CDASH Model allows the date of death to be collected on any CRF deemed appropriate by the applicant The death date should only be collected on 1 form.