Difference between RFSTDTC and RFXSTDTC

Difference between RFSTDTC and RFXSTDTC

This is an easy one ...

RFSTDTC is the reference date/time that YOU choose according to YOUR method. This can e.g. be the date/time of informed consent, can (but must not be) the date of first study drug/treatment exposure. It could also e.g. be the date/time of screening.
RFXSTDTC is indeed the date/time of first study drug/treatment exposure.

Important is that for RFSTDTC you choose a method that applies to all subjects in the same way. So RFSTDTC is "up to you".
RFXSTDTC isn't.

Hi Jozef,Thanks for your…

Hi Jozef,

Thanks for your response. Quick question on derivation of --DY variables. Should then the RFSTDTC variable be used or should we use RFXSTDTC ? In cases where we have NOT TREATED subjects i.e randomised however did not receive treatment, we will have RFSTDTC populated if we consider the screening date however RFXSTDTC as null. In that case should the --DY be null or should be calculated based on Screening date?

The Pinnacle validation rules are conflicting if we use our method to populate RFSTDTC (Not sure if we need to consider rule 1 or rule 2 ):

1.Subject Reference Start Date/Time (RFSTDTC) should be populated for all treated subjects, those where Actual Arm Code (ACTARMCD) is not equal to 'SCRNFAIL', 'NOTASSGN' or 'NOTTRT'.

2.Subject Reference Start Date/Time (RFSTDTC) should be populated for all randomized subjects, those where Planned Arm Code (ARMCD) is not equal to 'SCRNFAIL' or 'NOTASSGN'.

Difference between RFSTDTC and RFXSTDTC

--DY values are always based on RFSTDTC (not on RFXSTDTC). Remark that --DY can never be 0. It can either be <0 or >0 (special FDA math).
For the other questions, there can be conflicts between CDISC rules and FDA rules.
The best is to check the FDA "technical conformance guide" (https://www.fda.gov/media/122913/download). See e.g. page 19 for your specific question
For Pinnacle having conflicting validation rules I can of course not say anything. It is up to them to answer that one...

Learn a lot

Thanks for kindly explanations. I learn a lot from the answers.

In the recently released…

In the recently released SDTM 1.8 there are new --XDY / --XSTDY / --XENDY variables that allow calcualting day relative to RFXSTDTC.

Also introduced in SDTM 1.8 are two new variables in DM (RFCSTDTC / RFCENDTC) that are for use when the study includes a challenge agent.  There are corresponding --CDY / --CSTDY / --CENDY variables that use RFCSTDTC.

These variables are not currently in a released SDTM-IG though.  Perhaps the next release 3.4 will include them

SDTM 1.8 and -DY variables

Please take into account that the mentioned -XDY, -XSTDY and -XENDY variables of SDTM model 1.8 are essentially only meant for SENDIG-AR v.1.0. The current status is that they are not meant for any SDTMIG. See https://www.cdisc.org/standards/foundational/sdtm.

Also, it is very sad that *DY variables are and continue to be added to SDTM/SEND. They are completely unnecessary, as their values can be calculated "on the fly" by any modern (regulatory) review software in any modern computer language (including SAS). For example, they are being calculated "on the fly" by the open-source "Smart Submission Dataset Viewer". Having the *DY variables in SDTM/SEND leads to data redundancy which usually leads to errors and endanger data quality considerably.

SDTM 1.8 and -DY variables

While the draft versions of SDTM 1.8 and SENDIG-AR 1.0 indicated that the challenge variables were specific to SEND, this was changed during the public review cycle.

As such, while the current SDTM-IG 3.3 is based on SDTM 1.7 I would hope that SDTM-IG 3.4 which is currently in development and targetted for release in 2020 will be based on SDTM 1.8 (or later if new variables/concepts are required)

In the meantime, I am considering using the RFCSTDTC/RFCENDTC from SDTM 1.8 as supplemental variables in SUPPDM.
I agree that the corresponding *DY variables are not needed at the moment, but can see the benefit of using the new RFCSTDTC/RFCENDTC variables in SUPPDM, and then in ADSL