Review ask

As a clinical trial statistician or programmer, challenge anything in this benchmark: describe a problem in Comments, or propose a fix with the Edit button on any source file.

  1. Task: Would a real study need this derivation, specified this way? Does it follow CDISC ADaM: variable names, controlled terms, record structure? Flag any rule that is ambiguous or that a sponsor would handle differently.
  2. Inputs: Do they look like data collected in a real trial, and do they include the situations you would expect to meet in one?
  3. Expected output: Would independent QC programming reproduce every value from these inputs and rules?

The other tabs beside Comments are background for assessment, not under review.

Summary

Lifecycle: draftEditUnder review
What this benchmark means
README.md

Goal: demonstrate the aggregate derive step for #789: a binding reads a named intermediate that declares keep, so one row-scoped value is visible to every record the aggregate reduces.

Engine coverage: the Python engine implements this behavior. The R engine does not implement it yet.

Input: exposure records with sequence numbers (EXSEQ) and doses (EXDOSE), plus dose caps (CAPDOSE), which a subject may have more than one of.

Variables:

  • CUMDOSE: the cumulative dose over all of the subject's exposure records, after capping each record's dose at the subject's lowest cap. A subject with no cap has their doses summed uncapped, and a record with a missing dose counts as the full cap.

Mechanism: the DOSECAP intermediate sorts each subject's cap records by CAPDOSE and keeps the first, the lowest cap, so it holds one record per subject. The derive step binds CAP from DOSECAP.CAPDOSE for each exposure record, caps that record's DOSE with least, which ignores a missing value, and the reducer sums the capped values. The keep declaration is what makes the intermediate read valid. Each output row is built from the subject's first exposure record (EXSEQ 1), one row per subject.

Inputs

Under review
2 source files

input/ds.csv

Edit
2 rows
input/ds.csv
STUDYIDUSUBJIDCAPDOSE
PILOT7500
PILOT7150

input/ex.csv

Edit
3 rows
input/ex.csv
STUDYIDUSUBJIDEXSEQEXDOSE
PILOT71100
PILOT72200
PILOT73300

Expected output

Under review
1 expected row

expected/adex.csv

Edit
1 row
expected/adex.csv
STUDYIDUSUBJIDCUMDOSE
PILOT7400
Shaded columns are derived— = missing value

Comments and assessment materials

Comments

Signed in with GitHub; saved in repository Discussions

Mapping spec

Generated from the benchmark YAML; do not edit by hand

Dataset NameVariable NameVariable LabelTypeCodelist/Controlled TermsCoreComputational MethodOrigin
ADEXSTUDYIDStudy IdentifiercharacterCopy value from EX.STUDYID.Predecessor
ADEXUSUBJIDUnique Subject IdentifiercharacterCopy value from EX.USUBJID.Predecessor
ADEXCUMDOSECumulative Capped DosenumericAggregate SUM(CAPPED) over records matching on STUDYID and USUBJID, with DOSE as EX.EXDOSE, with CAP as CAPDOSE from the first DS record matching on STUDYID and USUBJID, ordered by DS.CAPDOSE, and a row with no match is an error, with CAPPED as least of DOSE and CAP.Derived
TemplateInclude when
exposureEX.EXSEQ = 1
VersionDateAuthorDescriptionReviewerSign-off
1.32026-09-29yamaa docs buildShow study codelist names, external dictionaries, and ISO 8601 formats in variable rows; list the document's codelist values and metadata
1.22026-09-29yamaa docs buildClassify ADaM copies from a declared input as Predecessor and recodes as Derived, and SDTM recodes of locally derived columns as Derived
1.12026-09-29yamaa docs buildResolve lookups into the donor record they select, and give every derivation shape a plain-language rule instead of its raw YAML
1.0yamaa docs buildInitial generation from spec.yaml

yamaa code

Runs the yamaa specification; its result must match the expected output

run.R

Edit
4 lines
library(yamaa)adex <- yamaa_domain("spec.yaml")$outputadex

run.py

Edit
4 lines
import yamaaadex = yamaa.yamaa_domain("spec.yaml").outputadex