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: Is this a specification error a study team could realistically make, and should the build stop on it rather than continue?
  2. Inputs: Do they trigger the failure for the reason the summary gives?
  3. 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

Lifecycle: reviewedEditUnder review
What this benchmark means
README.md

Goal: build one demographics record per subject, carrying the unique subject identifier (USUBJID) and the site identifier (SITEID).

Input: collected demographics records, each carrying the study identifier, the site identifier (SITEID) and the subject number (SUBJID).

Variables:

  • USUBJID would be the study, site and subject identifiers joined by hyphens, such as CATH-UCSD-0001; a record missing any of the three parts stops the run.
  • SITEID would be the study site identifier, as collected.

Note: the subject identifier must fit in 20 characters on every record. A site identifier long enough to push it past that limit rejects the run after the dataset completes, so no artifact is accepted.

How to fix

Decide which is authoritative: the width the study declares, or the site identifier the data carries. If the site identifier can be shortened at source, correct it there, so that every dataset referring to the subject keeps one value:

CATH,0003,STMARY

If the long site identifier is correct, raise the declared width to one that fits the longest value the study can produce, and change it wherever the subject identifier is described:

- name: USUBJID
  type: str
  derivation:
    str_concat:
      sources:
        - source: DM_RAW.STUDYID
        - literal: '-'
        - source: DM_RAW.SITEID
        - literal: '-'
        - source: DM_RAW.SUBJID
  verifications:
    - max_length:
        max: 30

Do not lower the bound below the values the study produces merely to make this input pass. A subject identifier that no longer fits its stated width is a defect wherever it is carried.

Expected failure

Edit
the run is rejected; no artifact is accepted
expected/error.yaml
phase
verification
condition
length_failed
requirement
REQ-0378
expected/error.yaml
phase: verification
condition: length_failed
spec_paths:
  - columns.USUBJID.verifications[0].max_length
requirement: REQ-0378
context:
  column: USUBJID
  max: 20
  failure_count: 1
  keys:
    - STUDYID: CATH
      USUBJID: CATH-STMARYSMONTREAL-0003

Inputs

Under review
1 source file

input/dm_raw.csv

Edit
3 rows
input/dm_raw.csv
STUDYIDSUBJIDSITEID
CATH0001UCSD
CATH0002MCGILL
CATH0003STMARYSMONTREAL

Unexpected Output

Under review
No artifact is produced

No fixture files in this directory.

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

Variable NameVariable LabelTypeLengthControlled Terms or FormatOriginCoreConversion DefinitionVariable TypeVariable OrderComments for Define
STUDYIDStudy IdentifierCharCollectedCopy value from DM_RAW.STUDYID.SDTM1
USUBJIDUnique Subject IdentifierCharDerivedConcatenate DM_RAW.STUDYID, "-", DM_RAW.SITEID, "-" and DM_RAW.SUBJID.SDTM2
SUBJIDSubject Identifier for the StudyCharCollectedCopy value from DM_RAW.SUBJID.SDTM3
SITEIDStudy Site IdentifierCharCollectedCopy value from DM_RAW.SITEID.SDTM4
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