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.
- 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.
- Inputs: Do they look like data collected in a real trial, and do they include the situations you would expect to meet in one?
- 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
README.mdGoal: 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_EOSnames 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.EOSDTis that record's start date; a subject with no such record, such as one who only failed screening, keepsEOSDTblank.
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 review2 source filesinput/dm.csv
Edit3 rows| STUDYID | USUBJID |
|---|---|
| YAMAA-01 | |
| YAMAA-01 | |
| YAMAA-01 |
input/ds.csv
Edit4 rows| STUDYID | USUBJID | DSCAT | DSDECOD | DSSTDTC |
|---|---|---|---|---|
| YAMAA-01 | DISPOSITION EVENT | COMPLETED | 2024-01-10 | |
| YAMAA-01 | DISPOSITION EVENT | COMPLETED | 2024-02-11 | |
| YAMAA-01 | DISPOSITION EVENT | SCREEN FAILURE | 2024-01-02 | |
| YAMAA-01 | DISPOSITION EVENT | SCREEN FAILURE | 2024-03-01 |
Expected output
Under review3 expected rowsexpected/adsl.csv
Edit3 rows| STUDYID | USUBJID | EOSDT |
|---|---|---|
| YAMAA-01 | 2024-01-10 | |
| YAMAA-01 | 2024-02-11 | |
| YAMAA-01 | — |
Comments and assessment materials
| Dataset Name | Variable Name | Variable Label | Type | Codelist/Controlled Terms | Core | Computational Method | Origin |
|---|---|---|---|---|---|---|---|
| ADSL | STUDYID | Study Identifier | character | Copy value from DM.STUDYID. | Predecessor | ||
| ADSL | USUBJID | Unique Subject Identifier | character | Copy value from DM.USUBJID. | Predecessor | ||
| ADSL | EOSDT | End of Study Date | character | Take 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 |
| Version | Date | Author | Description | Reviewer | Sign-off |
|---|---|---|---|---|---|
| 1.3 | 2026-09-29 | yamaa docs build | Show study codelist names, external dictionaries, and ISO 8601 formats in variable rows; list the document's codelist values and metadata | ||
| 1.2 | 2026-09-29 | yamaa docs build | Classify ADaM copies from a declared input as Predecessor and recodes as Derived, and SDTM recodes of locally derived columns as Derived | ||
| 1.1 | 2026-09-29 | yamaa docs build | Resolve lookups into the donor record they select, and give every derivation shape a plain-language rule instead of its raw YAML | ||
| 1.0 | yamaa docs build | Initial generation from spec.yaml |
yamaa
Comments
Signed in with GitHub; saved in repository Discussions