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: derive each subject's end-of-study date from their disposition records, checking that no subject has more than one end-of-study record.

Input: one spec.yaml declaring two datasets. DM carries one row per subject. DS carries disposition records: subject, category, decoded term, and start date.

Lookups:

  • DS_EOS names each subject's end-of-study record: a disposition event that is not a screen failure. The subject key is shared with the output, so it is inferred rather than restated. EOSDT is that record's start date; a subject with no such record, such as one who only failed screening, keeps EOSDT blank.

Note: the eligible records are checked for a repeated subject before any row is built, so the lookup needs no rule for choosing among them: a subject with two end-of-study records stops the run rather than taking either one. A screen-failure record is never eligible, so it may sit beside a subject's end-of-study record.

Inputs

Under review
2 source files

input/dm.csv

Edit
3 rows
input/dm.csv
STUDYIDUSUBJID
YAMAA-01
YAMAA-01
YAMAA-01

input/ds.csv

Edit
4 rows
input/ds.csv
STUDYIDUSUBJIDDSCATDSDECODDSSTDTC
YAMAA-01DISPOSITION EVENTCOMPLETED2024-01-10
YAMAA-01DISPOSITION EVENTCOMPLETED2024-02-11
YAMAA-01DISPOSITION EVENTSCREEN FAILURE2024-01-02
YAMAA-01DISPOSITION EVENTSCREEN FAILURE2024-03-01

Expected output

Under review
3 expected rows

expected/adsl.csv

Edit
3 rows
expected/adsl.csv
STUDYIDUSUBJIDEOSDT
YAMAA-012024-01-10
YAMAA-012024-02-11
YAMAA-01—
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
ADSLSTUDYIDStudy IdentifiercharacterCopy value from DM.STUDYID.Predecessor
ADSLUSUBJIDUnique Subject IdentifiercharacterCopy value from DM.USUBJID.Predecessor
ADSLEOSDTEnd of Study DatecharacterTake DSSTDTC from the DS record matching on the shared output keys, where DS.DSCAT = 'DISPOSITION EVENT' AND DS.DSDECOD <> 'SCREEN FAILURE', and no match yields blank.Derived
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)adsl <- yamaa_domain("spec.yaml")$outputadsl

run.py

Edit
4 lines
import yamaaadsl = yamaa.yamaa_domain("spec.yaml").outputadsl