Total core time: about 85 minutes.
| Section | Time | Type |
|---|---|---|
| When Do You Use This? + Learning Objectives | 5 min | Reading |
| Background: counting events, not measuring them | 20 min | Reading |
| Example 1: The ADAE spine and treatment emergence | 25 min | Worked example |
| Example 2: Occurrence flags and the denominator | 20 min | Worked example |
| What Can Go Wrong | 10 min | Reading |
| Exercises + Comprehension Check | 5 min | Practice / Self-test |
The course’s first OCCDS dataset, and the first session that reads an ADaM dataset as an input. For self-paced study, split after Example 1.
Every code chunk below is written so you can copy it into your R console (or an R script) and run it yourself, in the order shown. Run R from the project root, as in earlier sessions.
This session reads data/sdtm/ae.csv and, for the first time - data/adam/adsl.csv. Treatment emergence cannot be decided without the treatment dates ADSL carries, which is why ADSL came first.
A safety table needs every adverse event classified as treatment emergent or not, because an event that began before the first dose is not evidence about the drug. A reviewer asks which subjects had their first severe event while on treatment. Someone needs the percentage of subjects who experienced nausea, and gets a different answer depending on what they divide by.
None of those questions is about a measured value. There is no result to record, no unit, no change from baseline. There is only a list of things that happened, and questions about which of them count. That raises the question this session answers: what does an analysis dataset look like when there is nothing to measure: only occurrences to count?
Builds on ADaM Concepts, ADSL, and the SDTM AE domain from Events.
After completing this session you will be able to:
ASTDT, ASTDY and TRTEMFL, and explain why treatment emergence is an ADaM derivation rather than an SDTM factEstimated time: ~20 minutes (reading)
ADAE is one row per adverse event, carried from SDTM and answered against the treatment window: not what value was measured, but whether this event counts for this analysis, was it treatment emergent, and is it this subject’s first of its kind?
Every ADaM dataset you have met so far has been built around a measured value. In BDS there is AVAL, a PARAM that says what it is, and a baseline to compare it against. Adverse events have none of that. You do not measure an adverse event; you record that one occurred. Analysis then counts occurrences.
That difference is not cosmetic, and CDISC gives it its own structure and its own document. The Occurrence Data Structure (OCCDS) applies when three things hold (OCCDS v1.1, §1.1.2):
AVAL or AVALC, because “occurrences are counted in analysis.”The guide summarises the division in one sentence: “typically, findings data fit nicely into BDS, and events and interventions fit nicely into OCCDS” (OCCDS v1.1, §1.1.2). And it states the structural consequence bluntly, in OCCDS “there is no PARAM nor AVAL, for example” (OCCDS v1.1, §3.2). If you go looking for the variables that organised the last session, they are not here, and their absence is the design.
OCCDS v1.1’s own front matter says it is “based on the Analysis Data Model (ADaM) v2.1 and the ADaM Implementation Guide (ADaMIG) v1.2,” and it cites SDTMIG v3.3 section numbers throughout. This course targets ADaMIG v1.3 and SDTMIG v3.4, so that looks like a mismatch.
It is not. OCCDS v1.1 is CDISC’s designated companion to ADaMIG v1.3: the ADaMIG v1.3 documentation points to OCCDS v1.1 for occurrence data, and the v1.3 release package ships it. CDISC’s foundational standards are versioned on staggered cycles: a companion document is not reissued merely because the document it references moved on. Read the front matter as telling you when OCCDS was last revised, not as telling you which ADaMIG to pair it with.
This is worth internalising because you will meet it again. “The version numbers do not match” is rarely the same thing as “these documents do not go together.”
OCCDS defines a SubClass ADVERSE EVENT for the standard AE analyses. A dataset in it must have Class OCCURRENCE DATA STRUCTURE, is usually one record per record in the corresponding SDTM domain, and always takes AE as its SDTM input, with additional information from SUPPAE, FA and ADSL (OCCDS v1.1, §3.1.2).
It also carries a requirement this course cannot meet:
For the SubClass ADVERSE EVENT, it is required that all levels of terms for the primary path in the MedDRA hierarchy — System Organ Class (SOC), High Level Group Term (HLGT), High Level Term (HLT), Lowest Level Term (LLT), and Preferred Term (PT) — be included. For other OCCDS datasets, these variables are recommended… but not required (OCCDS v1.1, §3.2.3).
GLPX-1 has no MedDRA coding at all. AEDECOD is null on every row, because MedDRA is a licensed dictionary and this course does not fabricate coded terms: the same discipline that keeps it from inventing lab reference ranges or a half-life for a fictional compound. So the SubClass is out of reach.
The right response is not to fake the codes, and not to abandon the dataset. It is to build ADAE with Class OCCURRENCE DATA STRUCTURE and no SubClass, and the guide is unusually direct that this is correct rather than merely tolerated:
Data for a particular study that could have been coded but was not should use this structure, because analysis results are similar, and this will allow analysis programming to work the same way (OCCDS v1.1, §1.1.2).
That sentence is doing real work. It says uncoded occurrence data belongs in OCCDS, so that the analysis code you write today keeps working when the data is coded tomorrow. The supporting point is in §3.1.2: “not all OCCDS datasets that contain adverse event data will necessarily be of SubClass ADVERSE EVENT.” Uncoded is a legitimate state, not a broken one.
What it costs is specific, and it is worth working out precisely rather than by feel. The occurrence flags sit in two tables: the general ones in Table 3.2.6.1, and a second table titled MedDRA Occurrence Flag Variables (OCCDS v1.1, §3.2, Table 3.2.6.2). Whether we can build each one depends on what its derivation keys on:
| Flag | Keys on | Where CDISC files it | Buildable here |
|---|---|---|---|
AOCCFL |
first treatment-emergent record | Table 3.2.6.1 | Yes |
AOCCIFL |
maximum severity (ASEVN) |
Table 3.2.6.1 | Yes |
AOCCPFL |
preferred term (--DECOD) |
Table 3.2.6.1 | No |
AOCCPIFL |
preferred term + severity | Table 3.2.6.1 | No |
AOCCSFL |
system organ class | Table 3.2.6.2 | No |
AOCCSIFL |
system organ class + severity | Table 3.2.6.2 | No |
Read the middle column and the boundary is obvious. Read the right-hand one and it is not - the line falls across the two tables, not along them. AOCCPFL and AOCCPIFL sit in the general table, yet we cannot build them, because their derivations key on --DECOD. The table titled “MedDRA” contains some of what a dictionary costs you, not all of it.
So the rule to carry away is about derivations, not headings: the buildable set is bounded by which coded terms we lack (preferred term and system organ class) and that boundary cuts across CDISC’s table structure rather than following it. AOCCFL and AOCCIFL survive because they key on record order and on ASEVN, which come from severity and dates that GLPX-1 has. Everything keyed on a dictionary term goes, wherever it happens to be filed.
That is the general habit worth building. When a constraint bites (licensing, a domain you did not collect, a variable the vendor never sent) work out what each derivation depends on. Grouping in the standard is a useful signpost and an unreliable rule.
An adverse event that began before the first dose tells you about the subject, not the drug. TRTEMFL is the flag that makes the distinction, and it is the central derivation of this dataset. The IG gives the derivation directly (OCCDS v1.1, §3.2, Table 3.2.5.3):
If
ADSL.TRTSDT <= ASTDT <= ADSL.TRTEDT + x daysthenTRTEMFL = "Y"
where “the number x in this derivation is defined by the producer and often incorporates the known half-life of the drug.” TRTEMFL is Conditional in OCCDS generally and Required for the SubClass; for a dataset outside the SubClass it is “conditional on whether the concept of treatment emergent is a key feature of the analysis,” which for a safety dataset it plainly is.
Notice what that derivation depends on: three dates. No coded term appears anywhere in it. Treatment emergence is a pure timing question, which is why it remains fully available to us when the dictionary-based flags are not.
Notice also where two of those three dates come from: ADSL. You cannot decide whether an event was treatment emergent from the AE domain alone - SDTM AE does not know when the subject was dosed. This is the first time in the course that an ADaM dataset is an input to another ADaM dataset, and it is not incidental. It is why ADSL is built first and why it is required in a submission even when nothing else is.
TRTEMFL is not AETRTEM
SDTM can carry its own treatment-emergent flag as a Supplemental Qualifier, AETRTEM in SUPPAE (OCCDS v1.1, §3.2, Table 3.2.5.3). Where it exists, including it alongside TRTEMFL adds traceability, but the guide is explicit that “TRTEMFL may differ from AETRTEM due to different definitions, date imputation, and other analysis rules.”
This is the same lesson as ADSL’s population flags, which ADaM re-derives rather than copying from SDTM’s Supplemental Qualifiers (ADaMIG v1.3, §3.5). The analysis flag is the analysis’s own. GLPX-1 has no SUPPAE, so AETRTEM simply does not exist here, stated rather than invented.
ASTDT (“Analysis Start Date”) is “created from converting XX.--STDTC from character ISO 8601 format to numeric date format, applying imputation rules if specified in the statistical analysis plan (SAP) or metadata”; AENDT follows from --ENDTC (OCCDS v1.1, §3.2, Table 3.2.4.1). The original --STDTC and --ENDTC are carried across unchanged alongside them, for traceability.
Two consequences follow, and both matter.
First, imputation is a documented decision, not a default. If a partial or missing date is imputed, ASTDTF records the level of imputation, from the DATEFL codelist, and it is conditional precisely “on whether ASTDT (or the date part of ASTDTM) was imputed” (OCCDS v1.1, §3.2, Table 3.2.4.1). No imputation rule, no imputation, and ASTDTF stays null because nothing was imputed.
Second, ASTDY (“Analysis Start Relative Day”) uses a rule you have already met:
ASTDT - ADSL.TRTSDT + 1ifASTDT >= ADSL.TRTSDT, elseASTDT - ADSL.TRTSDT(OCCDS v1.1, §3.2, Table 3.2.4.1)
That is the no-day-zero convention from SDTMIG v3.4 §4.4.4: the same two-branch shape you implemented in The DM Domain. But the anchor has moved, and OCCDS says so in the variable’s own definition: ASTDY is “the number of days from an anchor date (not necessarily DM.RFSTDTC) to ASTDT” (OCCDS v1.1, §3.2, Table 3.2.4.1).
SDTM’s --DY counts from DM.RFSTDTC; ADaM’s ASTDY counts from whatever the analysis nominates, here ADSL.TRTSDT. The guide adds that ASTDY “may differ from --STDY due to date imputation and the option in ADaM to use a reference date other than SDTM’s RFSTDTC,” and recommends carrying AESTDY alongside when it exists, so both are visible. Same arithmetic, deliberately different origin, because analysis gets to choose its own reference point, and must then say which one it chose.
That parenthesis closes an arc this course has been building since The DM Domain. The study-day rule is fixed; the day it counts from is not.
One sentence in OCCDS is worth more than any variable definition in it (OCCDS v1.1, §3.2.1):
Be aware that only subjects with a record in an input SDTM domain would have a record in the analysis dataset. For this reason, it is recommended that population indicators and denominator counts for percentages be derived from ADSL and not from the occurrence analysis dataset.
A subject who had no adverse events has no row in ADAE. They still belong in the denominator of every incidence percentage, because they were dosed and observed and nothing happened. Compute “percent of subjects with nausea” from the event dataset and you have silently restricted the population to subjects who had some event, inflating every percentage in the table. Example 2 puts real numbers on how large that error is.
Estimated time: ~25 minutes (worked example)
Start with both inputs. This is the shape of every OCCDS build: the event records from SDTM, and the subject-level context from ADSL.
ae <- read_csv("data/sdtm/ae.csv", show_col_types = FALSE,
col_types = cols(.default = col_character()))
adsl <- read_csv("data/adam/adsl.csv", show_col_types = FALSE)
c(ae_rows = nrow(ae),
subjects_with_ae = n_distinct(ae$USUBJID),
adsl_subjects = nrow(adsl)) ae_rows subjects_with_ae adsl_subjects
389 262 400 Hold on to those three numbers. 389 event records belong to 262 subjects, but the trial has 400. The 138 subjects who had no adverse event are absent from AE entirely, and that gap is the denominator problem, visible before we have derived anything.
Now merge the subject-level variables and derive the analysis dates. AESEQ is what makes each row traceable back to its source: where rows come from a single SDTM domain, --SEQ supplies the whole row identifier, and the SRCDOM/SRCSEQ pair is the alternative for multi-domain sources (OCCDS v1.1, §3.2.2).
adae_spine <- ae |>
left_join(
adsl |> select(USUBJID, SUBJID, SITEID, TRT01A, TRTSDT, TRTEDT, SAFFL),
by = "USUBJID"
) |>
mutate(
AESEQ = as.integer(AESEQ),
ASTDT = as.Date(AESTDTC), # OCCDS §3.2, Table 3.2.4.1
AENDT = as.Date(AEENDTC),
ASTDTF = NA_character_, # nothing imputed, so nothing to flag
ASTDY = if_else(ASTDT >= TRTSDT, # no day 0; anchored to ADSL.TRTSDT
as.integer(ASTDT - TRTSDT) + 1L,
as.integer(ASTDT - TRTSDT))
)
adae_spine |>
select(USUBJID, AESEQ, AETERM, AESTDTC, ASTDT, TRTSDT, ASTDY) |>
head(4)# A tibble: 4 × 7
USUBJID AESEQ AETERM AESTDTC ASTDT TRTSDT ASTDY
<chr> <int> <chr> <chr> <date> <date> <int>
1 GLPX1-101-010 1 Constipation 2024-05-23 2024-05-23 2024-03-28 57
2 GLPX1-101-010 2 Nasopharyngitis 2024-06-23 2024-06-23 2024-03-28 88
3 GLPX1-101-027 1 Hypoglycaemia 2024-05-01 2024-05-01 2024-04-14 18
4 GLPX1-101-037 1 Diarrhoea 2024-07-05 2024-07-05 2024-04-19 78Note that AEDECOD came across in the join and is null throughout, that is the licensing constraint, present in the data rather than described in the abstract:
c(rows = nrow(adae_spine),
aedecod_populated = sum(!is.na(adae_spine$AEDECOD)),
distinct_aeterm = n_distinct(adae_spine$AETERM)) rows aedecod_populated distinct_aeterm
389 0 25 25 distinct verbatim terms, zero coded terms. Every analysis that needs a preferred term or a system organ class is unavailable, and every analysis that needs only timing and severity is unaffected.
AESEV is copied from SDTM untouched. The analysis version (recased for presentation) goes in ASEV, with ASEVN as its numeric counterpart, and the guide notes low intensity should correspond to a low value (OCCDS v1.1, §3.2, Table 3.2.8.1).
adae_spine <- adae_spine |>
mutate(
ASEV = recode(AESEV, MILD = "Mild", MODERATE = "Moderate",
SEVERE = "Severe"),
ASEVN = case_when(ASEV == "Mild" ~ 1L,
ASEV == "Moderate" ~ 2L,
ASEV == "Severe" ~ 3L)
)
count(adae_spine, AESEV, ASEV, ASEVN)# A tibble: 3 × 4
AESEV ASEV ASEVN n
<chr> <chr> <int> <int>
1 MILD Mild 1 243
2 MODERATE Moderate 2 124
3 SEVERE Severe 3 22This is the “same name, same meaning, same values” rule from ADSL doing its job (ADaMIG v1.3, §3.1.1, item 3). We wanted mixed case for the tables; AESEV carries an SDTM name, so it may not be touched, and the recased values go somewhere else. The controlled terminology confirms why that matters:
sev_code <- (ct("list") |> filter(term == "AESEV"))$clst_code[1]
ny_code <- (ct("list") |> filter(term == "NY"))$clst_code[1]
tibble(
variable = c("AESEV", "ASEV", "AESER"),
codelist = c(sev_code, sev_code, ny_code),
values = c("MILD/MODERATE/SEVERE", "Mild/Moderate/Severe", "N/Y"),
all_valid = c(
all(is_term(unique(adae_spine$AESEV), clst_code = sev_code)),
all(is_term(unique(adae_spine$ASEV), clst_code = sev_code)),
all(is_term(unique(adae_spine$AESER), clst_code = ny_code))
)
)# A tibble: 3 × 4
variable codelist values all_valid
<chr> <chr> <chr> <lgl>
1 AESEV C66769 MILD/MODERATE/SEVERE TRUE
2 ASEV C66769 Mild/Moderate/Severe FALSE
3 AESER C66742 N/Y TRUE AESEV and AESER come back TRUE. ASEV comes back FALSE, and that is the correct result. OCCDS marks ASEV with an asterisk meaning “variable may be subject to producer-defined controlled terminology” (OCCDS v1.1, §3.2, Table 3.2.8.1, footnote b). Mild is not a CDISC submission value and was never meant to be. It is the sponsor’s presentation choice, defined in the metadata rather than checked against a codelist.
This is the same point AGEGR1 made in ADSL and PARAMCD made in ADaM Concepts. A FALSE from is_term() means “not CDISC CT,” which is a finding only if the variable was supposed to be CDISC CT. Knowing which variables those are is the skill.
Now treatment emergence. We must choose the x in TRTEDT + x days:
TRTEM_WINDOW_DAYS <- 0L # sponsor decision. See the note below
adae_spine <- adae_spine |>
mutate(
TRTEMFL = case_when(
is.na(ASTDT) ~ NA_character_,
ASTDT >= TRTSDT & ASTDT <= TRTEDT + TRTEM_WINDOW_DAYS ~ "Y",
.default = "N"
)
)
count(adae_spine, TRTEMFL)# A tibble: 2 × 2
TRTEMFL n
<chr> <int>
1 Y 388
2 <NA> 1On x = 0. The IG says x “often incorporates the known half-life of the drug”: a real trial commonly counts events for some days after the last dose, because the drug is still present. GLPX-1 is a fictional compound, and inventing a half-life for it would be inventing a pharmacological fact to dress up an example. So the window here is exactly first dose to last dose inclusive, declared as a sponsor decision. Do not read x = 0 as the norm. In a real study x is a protocol- or SAP-level decision with a clinical justification behind it, and it is often greater than zero.
On the absence of any "N". Every one of the 388 datable events in GLPX-1 falls inside the treatment window: the earliest begins one day after first dose, the latest a week before last dose. So the flag comes out "Y" for all of them, and this trial contains no non-emergent event to show you. The simulator generated on-treatment events only.
That is a limitation of the data, not of the concept, and the honest move is to say so rather than manufacture a pre-treatment event to make a prettier demonstration. Real trials routinely have them: an event recorded at screening, a condition present before the first dose. The derivation above would assign those "N", and the safety tables would exclude them. In GLPX-1, x = 0 and x = 30 would give identical results, which itself tells you the window choice cannot be validated against this dataset, only declared.
One row behaves differently, and it is the defect you met in Events:
adae_spine |>
filter(is.na(ASTDT)) |>
select(USUBJID, AESEQ, AETERM, AESTDTC, ASTDT, ASTDY, ASTDTF, TRTEMFL)# A tibble: 1 × 8
USUBJID AESEQ AETERM AESTDTC ASTDT ASTDY ASTDTF TRTEMFL
<chr> <int> <chr> <chr> <date> <int> <chr> <chr>
1 GLPX1-103-199 1 Constipation <NA> NA NA <NA> <NA> Subject GLPX1-103-199 has an adverse event (constipation) with no recorded start date. Follow the consequences across the row:
ASTDT is null, because there was nothing to convert and no imputation rule was specified for this study.ASTDTF is null too, and that is the correct value. The imputation flag records the level of imputation applied. Nothing was imputed, so there is nothing to record. A populated ASTDTF here would be a lie about what we did.ASTDY is null, because it is arithmetic on a date we do not have.TRTEMFL is null - not "N".That last one is the judgement call, and it is worth being deliberate about. "N" asserts that the event was not treatment emergent. We do not know that. Absence of a date is not evidence of a date outside the window; it is absence of evidence. Coding it "N" would quietly move an unknown into the “not the drug’s problem” column, which is exactly the direction of error a safety analysis must not make by accident.
Null says what is true: this event cannot be classified. A real study would resolve it, query the site for the date, or apply the SAP’s imputation rule and set ASTDTF accordingly. Both are decisions someone must make and document. Neither is a default.
Estimated time: ~20 minutes (worked example)
Occurrence flags answer “is this row the first of its kind for this subject?” They exist because a subject who reports nausea four times should count once in an incidence table. The derivation given for AOCCFL is “sort the data in the required order and flag the first treatment emergent record for each subject” (OCCDS v1.1, §3.2, Table 3.2.6.1), so the sort comes first, and the flags key on TRTEMFL.
adae <- adae_spine |>
arrange(USUBJID, ASTDT, AESEQ) |>
group_by(USUBJID) |>
mutate(
te_ = !is.na(TRTEMFL) & TRTEMFL == "Y",
maxsev_ = if (any(te_)) max(ASEVN[te_], na.rm = TRUE) else NA_integer_,
ismax_ = te_ & !is.na(ASEVN) & !is.na(maxsev_) & ASEVN == maxsev_,
AOCCFL = if_else(te_ & cumsum(te_) == 1L, "Y", NA_character_),
AOCCIFL = if_else(ismax_ & cumsum(ismax_) == 1L, "Y", NA_character_)
) |>
ungroup() |>
select(-te_, -maxsev_, -ismax_)
c(AOCCFL_Y = sum(adae$AOCCFL == "Y", na.rm = TRUE),
AOCCIFL_Y = sum(adae$AOCCIFL == "Y", na.rm = TRUE),
subjects_with_te_event = n_distinct(adae$USUBJID[!is.na(adae$TRTEMFL)])) AOCCFL_Y AOCCIFL_Y subjects_with_te_event
261 261 261 261 subjects have at least one treatment-emergent event, and each gets exactly one AOCCFL and one AOCCIFL. Not 262, subject 103-199, whose only event has no date, has no classifiable event and therefore no first occurrence to flag. The missing date propagates all the way to the occurrence flags, which is what a missing date should do.
The two flags are easiest to understand on a subject with several events:
adae |>
filter(USUBJID == "GLPX1-101-147") |>
select(AESEQ, AETERM, ASTDT, ASTDY, ASEV, ASEVN, TRTEMFL, AOCCFL, AOCCIFL)# A tibble: 4 × 9
AESEQ AETERM ASTDT ASTDY ASEV ASEVN TRTEMFL AOCCFL AOCCIFL
<int> <chr> <date> <int> <chr> <int> <chr> <chr> <chr>
1 1 Diarrhoea 2024-04-28 51 Mild 1 Y Y <NA>
2 2 Nausea 2024-05-09 62 Mild 1 Y <NA> <NA>
3 3 Dizziness 2024-05-12 65 Mild 1 Y <NA> <NA>
4 4 Nasopharyngitis 2024-07-20 134 Moderate 2 Y <NA> Y | What you see | What it means |
|---|---|
Four events, all TRTEMFL = "Y" |
All began during the treatment window. |
AOCCFL = "Y" on the diarrhoea at day 51 |
The subject’s first treatment-emergent event, by date. This is the row an “any adverse event” incidence count uses. |
AOCCIFL = "Y" on the nasopharyngitis at day 134 |
The subject’s first event at their maximum severity: the only Moderate one among four. This is the row a “worst severity per subject” table uses. |
| The two flags on different rows | The point of having both. “First event” and “worst event” are different questions, and a table that answers one must not be built from the other’s flag. |
Had this subject’s severities run the other way (Moderate first) both flags would have landed on the same row. That they can coincide is exactly why the distinction is easy to miss and worth deriving explicitly.
Now the error OCCDS warns about (OCCDS v1.1, §3.2.1). Here are the same subjects counted two ways:
with_ae <- adae |>
filter(TRTEMFL == "Y") |>
distinct(USUBJID, TRT01A) |>
count(TRT01A, name = "subjects_with_ae")
safety_n <- adsl |>
filter(SAFFL == "Y") |>
count(TRT01A, name = "safety_population")
with_ae |>
left_join(safety_n, by = "TRT01A") |>
mutate(
correct = round(100 * subjects_with_ae / safety_population, 1),
wrong = round(100 * subjects_with_ae / sum(subjects_with_ae), 1)
)# A tibble: 2 × 5
TRT01A subjects_with_ae safety_population correct wrong
<chr> <int> <int> <dbl> <dbl>
1 GLPX 10 mg 151 200 75.5 57.9
2 Placebo 110 200 55 42.1Run the chunk and compare the last two columns.
The correct column divides by the safety population from ADSL (200 subjects per arm) giving 75.5% on GLPX 10 mg and 55.0% on placebo. Those are incidence rates: the proportion of dosed subjects who had an event. A 20-point difference between arms, which is the finding.
The wrong column divides by the number of subjects who had events at all, giving 57.9% and 42.1%. Those two figures sum to 100%, which is the tell: it is not incidence at all but a share of affected subjects. It answers “of the people who had events, what fraction were on drug?”: a question nobody asked, that looks like the one they did ask, and that mechanically shrinks the apparent gap between the arms.
The 138 subjects with no adverse events never appear in ADAE. They are the entire difference, and they exist only in ADSL. This is why OCCDS tells you to take denominators from ADSL, and why ADSL is required in a submission even when nothing else is.
Finally, check the dataset against what OCCDS says it should be:
tibble(
check = c("one row per source AE record",
"AESEQ + USUBJID unique (datapoint traceability)",
"every row joins to an ADSL subject",
"TRTEMFL null only where ASTDT is null",
"at most one AOCCFL per subject"),
pass = c(
nrow(adae) == nrow(ae),
nrow(distinct(adae, USUBJID, AESEQ)) == nrow(adae),
all(adae$USUBJID %in% adsl$USUBJID),
all(is.na(adae$TRTEMFL) == is.na(adae$ASTDT)),
max(tapply(adae$AOCCFL, adae$USUBJID,
\(x) sum(x == "Y", na.rm = TRUE))) == 1
)
)# A tibble: 5 × 2
check pass
<chr> <lgl>
1 one row per source AE record TRUE
2 AESEQ + USUBJID unique (datapoint traceability) TRUE
3 every row joins to an ADSL subject TRUE
4 TRTEMFL null only where ASTDT is null TRUE
5 at most one AOCCFL per subject TRUE All five pass. The first is the OCCDS structural claim: one record per record in the source SDTM domain (OCCDS v1.1, §3.1.2), and the second is what makes each of those records traceable back to the exact SDTM row it came from.
This dataset is written to data/adam/adae.csv by R/build_adam.R, alongside ADSL, and the TLF sessions read it from there.
Estimated time: ~10 minutes (reading)
Computing percentages from the event dataset. The single most consequential error in this session, and the easiest to make because the code runs and returns plausible numbers. Denominators come from ADSL (OCCDS v1.1, §3.2.1). If a percentage’s denominator was not counted in ADSL, check it again.
Treating TRTEMFL as an SDTM fact. It is derived in ADaM, from ADSL’s dates and the sponsor’s window. Where SDTM carries AETRTEM, the two “may differ due to different definitions, date imputation, and other analysis rules” (OCCDS v1.1, §3.2, Table 3.2.5.3), and the analysis uses the ADaM one.
Coding an unclassifiable event as "N". A missing date means “we do not know,” not “not treatment emergent.” Null is the honest value, and it keeps the row visible as something requiring resolution.
Imputing silently. If you apply an imputation rule, ASTDTF must record the level of imputation (OCCDS v1.1, §3.2, Table 3.2.4.1). An imputed date with no flag is an assertion presented as an observation.
Recoding AESEV in place. Same-name variables must keep SDTM’s values (ADaMIG v1.3, §3.1.1, item 3). Recased or regrouped severity goes in ASEV, ASEVN or SEVGRy.
Expecting PARAM and AVAL. They do not exist in OCCDS (OCCDS v1.1, §3.2). Reaching for them is a sign the data might belong in BDS, or that the analysis question has been misread.
Claiming SubClass ADVERSE EVENT without the MedDRA hierarchy. The SubClass requires all five levels of the primary path (OCCDS v1.1, §3.2.3). A dataset labelled with a SubClass it does not satisfy is a metadata error a validator will find.
“OCCDS is just BDS without the value column.” It is a different structure for a different kind of question. BDS analyses measurements against a baseline; OCCDS counts occurrences within a population. The absence of AVAL follows from that, rather than defining it.
“AOCCFL marks the first adverse event.” It marks the first treatment-emergent one. Events outside the window are not candidates, which is why the flags are derived after TRTEMFL and not before.
“Uncoded data means we cannot build ADAE.” OCCDS says the opposite: data that could have been coded but was not should use this structure (OCCDS v1.1, §1.1.2). What is lost is the dictionary-keyed subset of analyses, and CDISC tells you exactly which those are.
“Every ADaM dataset is built from SDTM.” ADAE is built from SDTM AE and from ADSL. Analysis datasets feed each other, and ADSL feeds almost everything.
Practice: Exercise 5: ADAE.
TRTEMFL needs ASTDT, TRTSDT and TRTEDT. Which of those three come from ADSL, and what does that tell you about the order in which analysis datasets must be built?ASTDTF null for subject 103-199’s undated event, when the date is certainly not known?AESEV from MILD to Mild directly, arguing the meaning is unchanged. Which rule does this break, and what should they do instead?TRTSDT and TRTEDT come from ADSL; only ASTDT derives from the AE domain. SDTM AE has no knowledge of when the subject was dosed, so ADSL must exist before ADAE can be built. Analysis datasets are a dependency graph, and ADSL is at its root, which is why it is required in a submission even when nothing else is.ASTDTF records the level of imputation applied, and nothing was imputed. This study specified no imputation rule (OCCDS v1.1, §3.2, Table 3.2.4.1). The flag describes what the derivation did, not what the data lacks. Populating it would claim an imputation that never happened.AOCCPFL and AOCCPIFL (keyed on the preferred term, --DECOD), plus AOCCSFL and AOCCSIFL (keyed on system organ class). Look in both occurrence-flag tables, not just the one titled MedDRA Occurrence Flag Variables: AOCCSFL and AOCCSIFL are in Table 3.2.6.2, but AOCCPFL and AOCCPIFL sit in the general Table 3.2.6.1 and are dictionary-dependent all the same. The reliable test is what each derivation keys on, not which table it appears in. Coded data would also make SubClass ADVERSE EVENT reachable (OCCDS v1.1, §3.2.3).AESEV codelist (C66769), whose submission values are uppercase. The recased version belongs in ASEV, which is producer-defined terminology and carries no CDISC codelist to violate.