SUPP-- datasets are decommissioned and replaced by NS--

Rule

NS-001

Category

Structural

Basis

Confirmed Traceable to the published specification text cited below.

Detectability

Define-XML conclusive The Define-XML settles this one way or the other. No further evidence is needed to know whether it applies.

Finding type

Impact

Applies to

SDTMIG 3.2, 3.3, 3.4

What changes in v4.0

SDTMIG v4.0 states that "Supplemental Qualifiers (SUPP--) has been decommissioned and replaced with Non-Standard Variables (NS--) in Section 8, Datasets for Representing Relationships, and throughout the IG". The vertical one-row-per-QNAM structure with an always-character QVAL is replaced by a horizontal NS-- dataset holding one row per parent record, so values keep their native data type and each non-standard variable gets its own column with real variable-level metadata in Define-XML. The two structures are not equivalent, so the move is a redesign rather than a reshape. Section 8.2 requires one NS-- record per parent record and a one-to-one correspondence between a domain dataset and its NS-- dataset; requires IDVAR to be the parent domain's --SEQ (except in NSDM, where IDVAR and IDVARVLN are null); replaces the character IDVARVAL with the numeric IDVARVLN; provides no columns at all for QLABEL, QORIG or QEVAL; requires NSV names to follow the variable-naming conventions and to begin with the domain abbreviation; and lists content that must not become an NSV — subject-level objective data belonging in SC, findings interpretations that should be an additional test code and result, comments belonging in CO, and data not directly related to a parent record.

What to do about it

Rebuild this SUPP-- dataset as an NS-- dataset, treating it as a content review rather than a transpose. Expect to work through, at minimum: which QNAM values are legitimate non-standard variables at all and which the IG routes to SC, CO or an additional test code; parent resolution, since IDVAR must be the parent --SEQ and any SUPP record keyed on something else has to be re-resolved before it can be placed; the IDVARVAL-to-IDVARVLN change from character to numeric; cardinality, because two SUPP records carrying the same QNAM for one parent record have no NS-- representation and need a decision; restoring type, length and codelist metadata that QVAL flattened to character, which the Define-XML cannot tell you and the source conversion code can; QLABEL, which becomes Define-XML variable metadata; QORIG, which becomes Define-XML Origin; QEVAL, which has no NS-- column and no stated target, so evaluator provenance has to be reconciled deliberately; NSV naming against the conventions and against the Appendix C1 name codes; and any RELREC entry or downstream ADaM code that reads the SUPP-- structure. If the parent domain is split, its NS-- dataset must be split the same way.

What the scan can and cannot see

The Define-XML declares this dataset as a supplemental qualifier dataset, which is the whole condition: every SUPP-- dataset must become an NS-- dataset. What the conversion contains - how many QNAM values, whether any parent record duplicates one - is record-level and is named as work to do, never as something detected.