SDTM AE Domain Mapping Example

Tuesday's raw Adverse Event (AE) extract comes from Electronic Data Capture (EDC), and it is not yet Study Data Tabulation Model (SDTM)-ready. The source shows five subject-level AE pages, all with Adverse Event Yes/No (AEYN) equal to Yes, across sites 74001 and 74003. For the demo subject at site 74001, the five events are alanine aminotransferase (ALT) Increase, aspartate aminotransferase (AST) Increase, Blood Bilirubin Increase, Confusion, and Delirium. We will map Unique Subject Identifier (USUBJID) and Adverse Event Term (AETERM), Medical Dictionary for Regulatory Activities (MedDRA) decoding to Adverse Event Decoded Term (AEDECOD), and International Organization for Standardization (ISO) 8601 dates. Then we add deterministic Adverse Event Sequence Number (AESEQ) with Supplemental Qualifiers for Adverse Events (SUPPAE), and triage validation findings; any value or Statistical Analysis System (SAS) line shown comes from the material facts, and missing information is flagged, never invented.

In this scene, we focus on identifiers and the verbatim term rule for the Adverse Event Term, or AETERM. The Study Data Tabulation Model, or SDTM, requires a Unique Subject Identifier, USUBJID, built once with catx, joining the study identifier, site identifier, and subject identifier with hyphens. That same USUBJID must appear identically across every domain, so never reuse the Electronic Data Capture subject number alone. For AETERM, store the verbatim term exactly as collected, stripped only of surrounding blanks, so terms like 'Confusion' stay as-is. Standardization belongs in the Adverse Event Decoded Term, AEDECOD, never by rewriting AETERM, because cleaning AETERM breaks the reviewer's ability to reconcile the submission against the Case Report Form and coding-file joins break.

The Adverse Event Dictionary-Derived Preferred Term, or AEDECOD, comes only from the version-pinned Medical Dictionary for Regulatory Activities coding deliverable—never typed from memory or guessed. In the delivered row, "ALT Increase" maps through the hierarchy: Lowest Level Term "ALT increased", Preferred Term "Alanine aminotransferase increased", High Level Term "Liver function analyses", High Level Group Term "Hepatobiliary investigations", and System Organ Class "Investigations". Pin one MedDRA version per data cut, declare it in define-XML, and avoid uncontrolled recoding that causes MedDRA drift and silently changes adverse event summaries. When coding is pending, AEDECOD stays blank, the row still ships, and an open query ID tracks the gap—guessing a term is a submission defect; the related hierarchy variables and their numeric codes ride with the same deliverable.

CDISC, the Clinical Data Interchange Standards Consortium, defines AESEV, Adverse Event Severity, with three controlled terms: MILD, MODERATE, and SEVERE; raw severity scales collapse into these terms through explicit decision rows in your mapping specification. AESER, Serious Event, maps to Y or N via a decision table, and the six seriousness criteria get Y only when the Case Report Form, or CRF, box is checked. A blank criterion means the box was left unchecked, while an explicit 'No' means the criterion was denied; never default a blank to N. For quality control, or QC, every record with AESER='Y' must have at least one criterion equal to 'Y'. A serious event with no criterion triggers a data query. In the delivered data, all five events have AESER='N', and the six criterion columns are blank.

Every --DTC in the Study Data Tabulation Model, or SDTM, is a character International Organization for Standardization 8601 string, exactly as collected. So the adverse event start date/time, AESTDTC, and adverse event end date/time, AEENDTC, are never SAS numeric dates. The delivered rows show AESTDTC='2019-05-20' with AESTDY=13 for the alanine aminotransferase (ALT) and aspartate aminotransferase (AST) events, and AESTDTC='2019-05-17' with AESTDY=10 for the later three events. Partial dates like 'YYYY-MM' are valid and ship unchanged; completing them changes clinical meaning. If the end date is missing or unknown, AEENDTC stays missing and you raise a data query; an ongoing event carries the adverse event end relative to reference period flag, AEENRF='ONGOING', with AEENDTC blank. Imputation, when the Statistical Analysis Plan calls for it, happens later in the Analysis Data Model, or ADaM — never in SDTM.

Adverse Event Sequence Number (AESEQ) must be deterministic because SUPPAE, or Supplemental Qualifiers for Adverse Events, depends on it. Never reuse Electronic Data Capture (EDC) row or event numbers for AESEQ. In the delivered extract, AEREFID (6, 7, 4, 8, 9) is the source reference, while AESEQ (1-5) is the derived, reproducible sequence. SUPPAE rows link back through IDVAR equals AESEQ and IDVARVAL, so any rerun that reshuffles sequence numbers silently orphans the supplemental qualifiers attached to those records. For supplemental data, values with no adverse event home go vertical to SUPPAE, such as nab-paclitaxel-specific action taken and relationship beside the standard action taken and causality variables. A stable sort order on subject, start date, and term, then aeseq equals underscore n underscore after sorting, keeps downstream merges reproducible.

This checkpoint confirms your mastery of the core Study Data Tabulation Model (SDTM) Adverse Event (AE) mapping concepts before we apply them to real rows. Question 1 asks how the Unique Subject Identifier (USUBJID) and the Reported Term for the Adverse Event (AETERM) are mapped, and the correct answer is A. Option A is right because USUBJID must uniquely identify the subject in the study, while AETERM must remain the verbatim source term and not be changed into a coded or cleaned version. Question 2 asks how to use the Medical Dictionary for Regulatory Activities (MedDRA) version when creating the Dictionary-Derived Term (AEDECOD), and the correct answers are A and C. A and C are right because AEDECOD must come from the sponsor's official MedDRA coding deliverable using the exact MedDRA version that produced the code, and pinning that version prevents version drift across the clinical database, safety reports, the coding deliverable, SDTM, and downstream analyses. Question 3 asks which statements are consistent with SDTM AE mapping rules when finalizing records and creating the Supplemental Qualifiers for Adverse Events (SUPPAE), and the correct answers are A, B, and C. The AE sequence-number variable (AESEQ) must be assigned with a deterministic rule so each AE record has a stable sequence number and SUPPAE can use it as an identifier; record N when the source explicitly says No for a seriousness criterion but leave the variable blank when the criterion was not evaluated; and preserve partial date information in the adverse event start date/time (AESTDTC) without adding artificial day or month components.

In this walkthrough, we review five delivered Adverse Events (AE) rows from the Study Data Tabulation Model (SDTM) domain and its Supplemental Qualifiers for Adverse Events (SUPPAE). These are delivered rows, not raw Electronic Data Capture (EDC) source lines. For the demo subject, the first two events are in the safety follow-up epoch starting 2019-05-20, while the next three are in the treatment epoch starting 2019-05-17. Look at the focal row, sequence number 1: the verbatim term is 'ALT Increase', the coded term is 'Alanine aminotransferase increased', severity is 'MILD', seriousness is 'N', and relationship is 'RELATED'—all Controlled Terminology (CT) mappings. Outcome is 'NOT RECOVERED/NOT RESOLVED', start study day is 13, and the end relative to reference is 'ONGOING' with the end date blank; classify values by origin: verbatim, coding, CT, collected International Organization for Standardization (ISO) 8601, derived, or supplemental.

This segment is hands-on, so pause the video and open the exercise on the website at jaimeyan.com/learn. There you will practice routing each Supplemental Qualifiers for Adverse Events (SUPPAE) row to its correct parent adverse event (AE) row, matching qualifiers such as action taken and relationship to the right event term through the Adverse Event Sequence Number (AESEQ), and you will run straight into the classic identity trap where the Identifying Variable Value (IDVARVAL) is character while the parent AESEQ is numeric. Try it right after the video, and take the explicit conversion seriously, because that detail is exactly what the exercise is built to teach.

Validate every rebuilt domain with the Clinical Data Interchange Standards Consortium (CDISC) Open Rules Engine, or CORE. CORE is free and open source, its rules are public YAML Ain't Markup Language files, and output gives one finding per row. Triage by Rule ID and record a disposition for every finding: fixed, or waived with a written reason, so a waiver ships with its justification. Run CORE in continuous integration per data drop, and keep triage log as a versioned, reviewer-accessible file beside the code. But a clean run covers what its rules express, so cross-domain contradictions, such as the same event in adverse event and medical history, need eyeball quality control listings. Finally, agents may invent Medical Dictionary for Regulatory Activities terms or complete partial dates, so join real coding source and diff every date string against collection.

This checkpoint covers three Study Data Tabulation Model (SDTM) Adverse Events (AE) mapping decisions. For the single-choice question, when you combine raw safety data, a Medical Dictionary for Regulatory Activities (MedDRA) coding deliverable, and a decision-table mapping to build the SDTM.AE domain, the correct answer is B: keep the Adverse Event Reported Term (AETERM) exactly as reported, take the Adverse Event Decoded Term (AEDECOD) from the coding deliverable, and often set the Adverse Event Body System or Organ Class (AEBODSYS) from the dictionary hierarchy or decision-table mapping. That preserves traceability because neither the coding deliverable nor the decision table should rewrite the verbatim term. For the multiple-select question about an ongoing AE with reported start date '2021' and no end date, the correct answers are A and C: the SDTM.AE domain can store the Adverse Event Start Date/Time (AESTDTC) as the International Organization for Standardization (ISO) 8601 partial date '2021', and the Analysis Data Model (ADaM) layer is where imputed analysis dates and their flags, such as Analysis Start Date (ASTDT) and Analysis Start Date Imputation Flag (ASTDTF), belong. Partial dates stay as reported in SDTM for traceability, imputation belongs in ADaM, and the Adverse Event End Date/Time (AEENDTC) should remain unpopulated for an ongoing event rather than forced to an arbitrary far date. For the short-answer question, the model answer is that the Adverse Event Sequence Number (AESEQ) must be made deterministic by adding a unique raw record identifier as the final sort key, and the AE-to-Supplemental Qualifiers for Adverse Events (SUPPAE) merge must convert numeric AESEQ to trimmed character—for example with strip(put(AESEQ,best.))—before matching on the unique subject identifier and the Identifying Variable Value (IDVARVAL), because blank Adverse Event Seriousness (AESER) cannot be treated as AESER='N' when deriving an analysis serious-event flag, and a clean Clinical Data Interchange Standards Consortium (CDISC) Open Rules Engine (CORE) run only confirms structural conformance, not cross-domain contradictions such as an AESER='Y' record lacking consistent supporting data elsewhere.

Keep the Adverse Event Term, or AETERM, verbatim, and get the Adverse Event Dictionary-Derived Term, or AEDECOD, only from a version-pinned Medical Dictionary for Regulatory Activities, or MedDRA, deliverable; never guess a pending code. Map Adverse Event Severity, or AESEV, and Adverse Event Seriousness, or AESER, through decision tables; leave seriousness criteria blank unless checked, and never default to N. Ship date/time variables exactly as collected, partials included, and the Adverse Event Sequence Number, or AESEQ, is deterministic because Supplemental Adverse Events, or SUPPAE, links depend on it. Route collected values with no Study Data Tabulation Model, or SDTM, home to SUPPAE, validate with the standard rules engine per build, and record a disposition for every finding. For further reading, see the source article plus the previous and next pieces; all values trace to the provided extracts, with no patient data invented and material gaps flagged.