The validation algorithms for rules SD0021 and SD0022 were changed to be more accurate.
My guess is that your data do not include an –OCCUR variable, and because of that the SD0022 check was not executed in the previous version.
Sergiy
SD1044: In most cases custom domains are efficacy data with expected baseline values.
SD1045/SD1046: According to SDTM IG you should capture only violations of I/E criteria. Therefore there is no need to include records with ‘U’ values.
Hi Sergiy,
I have the same issue with check SD0021 (Missing value for CMENRF, when CMENDTC is NULL and CMOCCUR is not 'N')
In my dataset I have CMENTPT=null, CMOCCUR=null, CMPRESP=null
Based on SDTM IG, CMENRF is permissible and CMOCCUR can be null for medications not specifically solicited on CRF. Would you please let me know what is the intention of this check?
Thank you and looking forward to your response.
Vanessa
Hi Vanessa,
Thank you for a good point about pre-specified treatments or events!
I think that we can handle such cases by using additional condition "... or --STAT='NOT DONE'" to exclude those records from the check.
New Description="At least of End Date/Time of Event or Exposure (--ENDTC) or End Relative to Reference Period (--ENRTPT) variables values should be populated, or Occurrence (--OCCUR) variable should have 'N' value, or Completion Status (--STAT) variable value should be ‘NOT DONE’, when End Relative to Reference Period (--ENRF) variable value is NULL"
Kind Regards,
Sergiy
Hi,
with the new OpenCDISC version 1.3 we are now getting the following warnings/errors that did not fire for the same datasets with version 1.2.1 and we also could not find any information in the SDTM IG 3.1.2 that justify those warning/errors:
SD0021 "Missing value for --ENRF, when --ENDTC is NULL and --OCCUR is not 'N'" (same for SD0022 and --STRF, --STDTC): why is this check needed at all and as --ENRF, --STRF are permissible and also --ENDTC, --STDTC are sometimes permissible this message is only making sense when both variables are present in the dataset, it would maybe make sense to restrict this check to those cases?
SD1044 "No --BLFL variable in custom Findings domain": as --BLFL is not expected in all the SDTM Findings domains we don't have it included in all of our custom domains => is this warning really necessary?
SD1045/SD1046 "Inconsistent values for IEORRES/IECAT": we are also putting the not answered Inclusion/Exclusion criteria into the IE domains and put IEORRES = U in these cases, I couldn't find anything that says that U is not a valid value for the IEORRES as it's part of the NY terminology.
Would be great if some of you can let me know where I can find the justification for these messages in the CDISC documents so that we are able to decide if we have to change something in our implementation or just ignore those messages.
thanks!
best regards,
Christina