4 Radnor Corporate Center
Suite 350
Radnor, PA 19087
+1 (888) 507-2270
SE0055 SEND/Dataset variable type mismatch
SE0055 SEND/Dataset variable type mismatch
Hi Mike,
There are now RESTful web services available for this kinds of checks. They cover SDTM/SEND versions 1.2 to 1.4, with 1.5 soon to be implemented.
Any application can use these web services (including the one(s) you are using). The descriptions can be found at:
http://xml4pharmaserver.com/WebServices/index.html.
For the one you need, look under "Get the SAS datatype for a given variable". All these web services use content that comes from CDISC-SHARE.
Further information
The discrepency becomes a difference for the variables LBORNRLO and LBORNRHI for SEND version 3.0, and SDTM and SEND Version 3.1.
SDTM and SEND version 3.1 show the LBORNRLO and LBORNRHI as variable type of "Char", in other words text.
SEND 3.1 currently is not supported by the FDA. The preclinical community must currently use SENDIG 3.0.
SEND Version 3 specifies LBORNRLO and LBORNRHI as variable type of "NUM".
Yes the user can change the configuration of the community validator to correct this, however will the FDA do this correction in their configuration.
Investigating
Lou Anne Kramer has brought this to my attention. I will get back to you.
LBORNRLO and LBORNRHI update
Hi Mike,
LBORNRLO and LBORNRHI variables were switched from "float" to "text" based on a request from SEND team. These variables were incorrectly listed as "Num" in SENDIG v3.0.
Regards,
Max
It appears there may be an error in the SEND Config file. Up until Pinnacle21 Community version 2.1.2, the dataset variable types seemed to match the SENDIG.
Now they appear to no longer be in alignment. This is returning false errors I believe. I noticed this case in the LB Domain, where the dataset type according to SENDIG is Num or numeric for LBORNRLO and LBORNRHI. Our LB.xpt file contains this information at the metadata level, but the validator returns error SE0055/FDAN032. Prior versions had this type as float.
Or is the issue tied to fact that this permissible column was not populated but present, even though that is a different rule, which is a warning not an error.