If you only have a hammer ...

... everything looks like a nail.
and if you only know XPT format, everything looks like a table...

Why this comparison? The trigger for this was a recent proposal of the CDISC QRS ("Questionnaires, Ratings and Scales") team to add a table to SDTM, a so-called "Trial Lookup Table" ("TL" domain), containing metadata, like information about instruments. They provided a number of examples, one with codes assigned to questions on a questionnaire, one about questions on a questionnaire sharing an identical set of possible answers ("scale"), and one about "logically skipped items". The latter sounds very much like CDISC-ODM "skip questions", but we are unfortunately not allowed to use ODM nor its "tabular" equivalent Dataset-XML for submissions.

Essentially, the table ("domain") they propose is nothing else than an "entity-attribute-value" model, a type of tables that can contain almost everything as it is about key-value pairs.

For example, for the simple case that a question can have answers ranging from 0 to 4:

 The proposed table is:

i.e. they need 5 rows for explaining to the reviewer that for that specific question (specified by TLVAR1, TLVARVAL1, ...) the possible values are 0 to 4.
That there is an ODM file with the study design that exactly states this in a much simpler way does not come up in the mind of the people who proposed this, as all they know is ... XPT tables!

Fortunately, we do have a few open-minded volunteers within CDISC who think further than tables ("the earth is not flat"), so Sally Cassells of Next Step Clinical Systems immediately demonstrated how this should be done in a much more simple way in the define.xml. For example, for the "scale sample", this information simply goes into a "ValueList" in the define.xml. The human-readable presentation of this (I do want to shield you from the XML although it is extremely simple) is:

 and for the scale values (0-4) themselves in the codelist (wich was already in the ODM in the study design):

 

So how do we educate these people who can only think in terms of tables that also the clinical research world is not flat? I would propose that every member of any of the SDTM development teams first must attend a define.xml course (where we explain such things very well), before they come with "yet-another-table" proposal.

And if you now say: "well Jozef, then you need to take an SDTM training too", I can say "I did"!