Reject Dates That Are Not Paired

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.

Task: Is this a specification error a study team could realistically make, and should the build stop on it rather than continue?
Inputs: Do they trigger the failure for the reason the summary gives?
Expected failure: Is this the right error, raised at the right point, and would it tell the programmer what to fix?

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

Summary

EditUnder reviewWhat this benchmark means

README.md

Goal: carry the treatment start date RFSTD and the death date DTHDT into a subject-level record, where the two dates must be present together or absent together.

Input: collected demographics records, one per subject, holding the treatment start date in RFSTDT and the date of death in DTHDTC.

Variables:

RFSTD would be the date treatment started, taken from RFSTDT in the demographics input.
DTHDT would be the date of death, taken from DTHDTC in the demographics input and missing when the subject has not died.

Note: a record with both dates present or both missing passes; a record with only one present fails the pairing, so the whole run is rejected and no dataset is accepted.

How to fix

Decide which absences the study allows, then assert each side on its own. When every subject must have a start date but only some have died, remove the pairing, require the start and leave death optional:

columns:
  - name: RFSTD
    type: date
    label: Reference Start Date
    derivation: DM.RFSTDT
    verifications:
      - not_missing: {}

When two dates truly travel together, keep the pairing and correct the offending row instead of loosening the rule.

Expected failure

Editthe run is rejected; no artifact is accepted

expected/error.yaml

phase: verification
condition: all_or_none_failed
requirement: REQ-0382

expected/error.yaml

phase: verification
condition: all_or_none_failed
spec_paths:
  - verifications[0].all_or_none
requirement: REQ-0382
context:
  verification_id: paired-death-dates
  failure_count: 1
  keys:
    - STUDYID: PILOT7
      USUBJID: P7-812

YAML specification

1 spec file

spec.yaml

Edit37 lines

1schema_version: "1.0"2domain: ADSL3keys: [STUDYID, USUBJID]4input:5  DM: {path: input/dm.csv, types: {RFSTDT: date, DTHDTC: date}}67output:8  path: adsl.csv9  columns: [STUDYID, USUBJID, RFSTD, DTHDT]1011columns:12  - name: STUDYID13    type: str14    label: Study Identifier15    derivation: DM.STUDYID1617  - name: USUBJID18    type: str19    label: Unique Subject Identifier20    derivation: DM.USUBJID2122  - name: RFSTD23    type: date24    label: Reference Start Date25    derivation: DM.RFSTDT2627  - name: DTHDT28    type: date29    label: Date of Death30    derivation: DM.DTHDTC3132verifications:33  # Every row must hold both dates or neither. A subject with a start date34  # and no death date (not known to have died) fails this.35  - all_or_none:36      id: paired-death-dates37      columns: [RFSTD, DTHDT]

Inputs

Under review1 source file

input/dm.csv

Edit2 rows

input/dm.csv
STUDYID	USUBJID	RFSTDT	DTHDTC
PILOT7		2023-01-02	2023-05-14
PILOT7		2023-02-10	—

Unexpected Output

Under review2 rows presented to the failing check - not an accepted artifact

expected/adsl.csv

Edit2 rows

expected/adsl.csv
STUDYID	USUBJID	RFSTD	DTHDT
PILOT7		2023-01-02	2023-05-14
PILOT7		2023-02-10	—

Shaded columns are derived— = missing value

Comments and assessment materials

Dataset Name	Variable Name	Variable Label	Type	Codelist/Controlled Terms	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	RFSTD	Reference Start Date	numeric	ISO 8601	Copy value from DM.RFSTDT.	Predecessor
ADSL	DTHDT	Date of Death	numeric	ISO 8601	Copy value from DM.DTHDTC.	Predecessor

Version	Date	Author	Description
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

How to fix

input/dm.csv

expected/adsl.csv

Comments

Mapping spec