CT2001 SUSTRTPT value not found in 'Relation to Reference Period (STRTPT)' non-extensible codelist

DURING

I have this message for the value "DURING": what source do you use to exclude this STENRF value from the legitimates ones for --STRTPT? A start date can be "during" something in the same way an end date can be, or am I missing something?

Cheers,

-- Thierry

According to SDTM IG 3.1.3 document ...

Hi Thierry,

According to SDTM IG 3.1.3 document, Controlled Terms for --STRTPT variables (CMSTRTPT, SUSTRTPT, CESTRTPT) are BEFORE, COINCIDENT, AFTER, U. This info was utilized for validation. It means that other standard terms (DURING, DURING/AFTER, ONGOING, UNKNOWN) from (STENRF) Codelist are not expected to be used for --STRTPT variable

SDTM IG 3.2 specs refer to CDISC CT Codelist (STENRF) rather than to a list of allowed terms. 

New versions of Validator also use a reference to complete (STENRF) Codelist. 

Kind Regards, 

Sergiy

DURING in --STENRF/--STRTPT

Hi Thierry,
Can you indicate which version of the validator you used and which SDTM-IG version?
I am currently looking into the source code to find out why you get this message.

Apologies

Hi Sergyi and Jozef,

Thank you for replying quickly.
Do you have something like the French "you should turn your tongue 7 times in your mouth before you speak"? (^_^)

I found the answer myself: STENRF is the codelist for, originally, --STRF and --ENRF, which are defined versus the reference period RFSTDTC to RFENDTC, do they can be DURING. But --STRTPT and --ENRTPT are defined versus --STTPT and --ENTPT, which are timepoints, so they cannot be DURING. In my case it' a pity, because I will have to use a SUPP variable instead (I need to define start vs. a custom period), but c'est la vie.

@Jozef: latest version 2.2, and SDTMIG 3.2. You can find the origin in the config file + the P21-amended version of the CT, where they define subcodelists of STENRF named STRTPT and ENRTPT.

Cheers,
-- Thierry

DURING in --STENRF/--STRTPT

You are of course completely right Thierry!
What I hate about the CDISC-CT is that they publish codelists (e.g.Y/N/U/NA) and then constraint such ONLY as TEXT in a non-machine-readable SDTM-IG and then even sometimes relax that constraint again as TEXT ONLY in the same non-machine-readable SDTM-IG. For example, I recently had a customer asking whether "U" was allowed as value for "CMOCCUR". The SDTM-IG essentially states (but a bit vague) that the possible values are "Y" and "N".
CMOCCUR "is permissible".
But Section 4.1.3 states:

4.1.3.: Use of “Yes” and “No” Values
...
Note: Permissible values for variables with controlled terms of “Y” or “N” may be extended to include “U” or “NA” if it is the sponsor’s practice to explicitly collect or derive values indicating “Unknown” or “Not Applicable” for that variable.

So my answer was; yes, "U" is allowed under certain circumstances, like when there is a checkbox for it on the CRF (which there was, and which triggered the question).

As you have experienced yourself, finding such things out manually from the SDTM-IG is not an easy task, even when one is highly experienced like you. Such rules should come in a machine-readable way in a machine-readable SDTM-IG. But that is "future work" ...