Checks not firing/Missing dataset configs

RE: Checks not firing/Missing dataset configs

Hi Diane, Rule IR4127 references the Standard-Units Upper and Lower Limit colums (__STNRHI and __STNRLO, respectively). The data that you've posted is from the Original-Units Upper and Lower Limit columns. It does make sense to apply the same sort of relationship-checking to those columns as well, but given that the description of rule IR4127 does not include that condition, it may be better off as part of a separate rule (under my interpretation, at least). Unfortunately I'm not able to replicate the false-positive given for IR4134 to give you a solution there, but something may have changed during development. Could you please let me know whether you're reading from a SAS Transport file or a delimited file? I'm not directly involved with writing the configuration files, but since our goal is 100% coverage of Janus/WebSDM expectations and validations, I'm sure that missing definitions will be added in future releases. Regards, Tim

IR4127 and IR4134

Guess I should have re-read the text of IR4127. You are right, it only talks about the ST variables. I was overzealous and added the OR variables to my checks. Sorry about that. For IR4134, I'm using the XPT file type. I can send it to you if that would help out. Note that it's not giving a false positive, it's not firing when I think it should be (false negative). The EXDOSE value is 0 with a missing EXDOSU. I think it should catch that. Thanks, Diane

RE: IR4127 and IR4134

It's no problem; I just wanted to make sure we were all on the same page. Oh, I apologise, I meant to have said false negative originally. I'll go ahead and create my own test dataset and see if I can recreate the problem, and if I'm unable to I'll ask you to send over your dataset if you don't mind. It definitely should be catching that, so hopefully we can discover why it isn't in your case. I'll get back to you soon and let you know if I was able to discover the cause. Regards, Tim

RE: IR4127 and IR4134

Hi Diane, I downloaded the version of the validator available from our Download page and was able to generate the expected validation error with the EXDOSE = 0 and EXDOSU being blank. Would you mind downloading the Validator again to be sure that there are no differences between the code that you are executing and the one that I used for the test? If you're still experiencing issues, then I'd be more than happy to run the test again with the dataset that you're using. Regards, Tim

Finally back to this...

Hi there, I've finally had some time to re-download the tool and check that it's not an issue with which version I have. I downloaded it this morning (12/15/08) and the tool still doesn't fire the check for a EXDOSE of 0 and and EXDOSU of missing. Could it be that the code in the tool is looking for an EXDOSE greater than 0? Good luck, Diane

RE: Finally back to this...

Thank you very much for the feedback. I actually should have considered the most likely cause earlier, my apologies. Does the dataset that you're testing with contain, in addition to EXDOSE and EXDOSU, the variables EXDOSTXT and EXDOSTOT? If not, you need to limit the scope of the validation to only include variables present. For example, on rule IR4134 When="__DOSE != '' @or __DOSTXT != '' @or __DOSTOT != ''" becomes When="__DOSE != ''" I'm not entirely sure if the additional variables are within the scope of the rule, but they are currently defined in its When condition. The current release of the Validator has the unfriendly habit of silently removing rules containing variables not available in the source, since we can't evaluate conditionals without a full set of data (or a method by which we can determine which non-existent variable conditions can be safely removed). In addition to any other changes related to this problem, the upcoming version will generate warning messages about rules that could not be run due to missing variables. Hopefully this is a relevant solution for you. If not though, if it wouldn't be too much trouble I'd appreciate it if you could send over your test dataset so that I could more readily analyze the problem. Regards, Tim

IR3134 Again

My dataset does not include EXDOSETX or EXDOSTOT. So that's the source of the difference. However, I don't understand why one would need all 3 of the possible variables in order for the check to fire. Can the logic be conditional on which variables exist in the data so the check doesn't disappear when only a subset of those variables exist? It's possible in SAS, but I don't know the limitations of your programming language (if there are any). It is our understanding that EXDOSE and EXDOSU a pair (and the pair of interest), and EXDOSTXT and EXDOSTOT are other independent variables not paired with anything else in the data. You might want to think about whether you really want to include EXDOSTXT and EXDOSTOT in this check at all. Thanks, Diane

RE: IR3134 Again

Hi Diane, Good to know that we finally got to the bottom of the issue. Thanks for being so patient. In regard to conditional variables, allowing this functionality is not necessarily complicated, but it poses some potential issues (from my perspective). The first issue is how we could best indicate which variables may be omitted, and the second being how we could be certain that the omission of those variables won't adversely modify the conditional logic. If you have any suggestions, I'd be happy to hear them. On a similar note, since the upcoming release of the Validator will warn about instances where this is an issue, it's also possible for the user to modify the conditional statement to match their source data. Admittedly this could be inconvenient for some users, but it also doesn't allow for potentially expected variables to be left out unintentionally. There are other ways to address that though, so we'll be sure to look at all the options and pick the most user-friendly one. In regard to the second point, I'm inclined to agree with that interpretation. I've passed the issue off to the rule-writers and hopefully they'll come to the same conclusion. Regards, Tim