How We Improved the SEND Validation Rules

June 11, 2020

For years, the validation rules for nonclinical data were just an extension of published SDTM rules. However, through active collaboration of Pinnacle 21, FDA and the industry over the past year, the SEND rules have been refined. We have modified many of the existing rules, removed some and added others.

On May 28th, Pinnacle 21 hosted a webinar in which Kristin Kelly discussed the changes that have been made to get the rules right for SEND. Learn more by browsing the webinar resources.

Webinar Resources

  • Download the slide deck
  • Watch the video above
  • Read the Q&A below

Answers to Your Questions

  1. Does the duplicate check refer to dataset keys in define.xml?
    SD1117 does not currently check against the keys in the define.xml. It checks against a specific set of qualifier and timing variables with the exception of variables that can be sponsor-defined, such as --SPID, --REFID, etc. There are future plans to possibly check against keys in the define.xml or to make the rule domain-specific in terms of common keys for some domains.
     
  2. What is the difference between codelist of VSTEST/VSTESTCD and SVSTST/SVSTSTCD? 
    The VSTESTCD/VSTEST codelists are the same codelists assigned for VSTESTCD/VSTEST in SDTM and SEND v3.0. When SEND v3.1 was published, SEND specific codelists had been created and assigned to VSTESTCD/VSTEST. These are SEND Vital Signs Test Code/ SEND Vital Signs Test (SVSTSTCD/SVSTST).
     
  3. Query related FDAB065 (EX domain) rule which was newly added, generally we are deriving EX domain based on EC. Does this rule also cover EC domain?
    No, because EC is not a required domain for submission. EX is required for Interventional studies. Also, EC is an SDTM domain and not used in SEND.
     
  4. Why is the rule checking for baseline flags not firing in the BW domain?
    SE2319 for SEND does not fire for BW because the FDA has requested in the TCG that it need only be populated for each test  for EG, LB, and VS domains in SEND.
     
  5. Regarding "NORMAL" and "UNREMARKABLE" of MISTRESC, when dataset is created based on SENDIG v3.0, MISTRESC have to use only "NORMAL" and when dataset is created based on SENDIG v3.0, MISTRESC have to use only "UNREMARKABLE". Can Pinnacle 21 output error/warning when MISTRESC use "NORMAL" in IG v3.1 datasets or MISTRESC use "UNREMARKABLE" in IG v3.0 datasets?
    That is something we can explore for future development.
     
  6. Does the Pinnacle 21 use the Codetable Mapping Files issued by CDISC? If not, do you have any plan to use them in future?
    Yes, we do check data at the value-level and so we use codetables that are similar to CDISC.
     
  7. Regarding a check for origin attribute of define.xml, why does pinnacle21 output error/warning for "Derived"? "Derived" is written in Define-XML v2.0 specification which FDA decides in FDA standard, so I think that pinnacle21 should not output error/warning.
    Pinnacle 21 should not output a 'Warning' when Origin is 'Derived' in an SDTM define.xml.  It will fire a 'warning' for SEND defines because the Origin value should be in uppercase as 'DERIVED' per the SENDIG and CDISC Errata for Define-XML v2.0.