b Bedeoan
on

 

Hello all,

I'm getting the below Warnings for a SC (Subject Characteristics datasets), but only when SCTESTCD is "ALTID" and SCSTRESC SCORRES are numeric values:

SE0015 - "Missing --STRESN value" - Identify records where --STRESC has numeric value, but --STRESN is null

SD0026 - "Missing units on value" - Original Units (--ORRESU) should not be NULL, when Result or Finding in Original Units (--ORRES) is provided

SD0029 - "Missing units on value" - Standard Units (--STRESU) should not be NULL, when Character Result/Finding in Std Units (--STRESC) is provided

Please consider the specific of this domain: "data that is either not normally expected to change during the study or whose change is not of interest after the initial collection[...] Examples: Hair Coat, Physical Markings". Therefor numeric values and measure units are unlikely to occur in SC.

So: are these 3 rules actually necessary for SC (they make the validation fail for a situation that doesn't seem to have a real consistency problem)?

Thanks!

Forums: Validation Rule Suggestions

s Sergiy
on April 4, 2012

Hi!

I agree with you. In majority of cases Units and --STRESN data are not collected in the SC domain. Therefore rules SE0015, SE0026 and SD0029 are not applicable for such studies. 

However SCORRESU, SCSTRESN and SCSTRESU are all permissible variables. If you do not collect those data, you should not create these variables in SC domain. If variables do not exist, the relevant validation checks are not executed. Therefore we have not recieved yet any complains about this potential source of false-positive errors. In practice SC domains do not usually have SCORRESU, SCSTRESU variables. SCSTREN is used also very rare.

Do you have any particular issue with those checks? If yes, we can discuss details here on forum or more confidentially using Contact form (on top of the page betwee Login and Search)   

Regards, 

Sergiy 

b Bedeoan
on April 5, 2012

The SCORRESU, SCSTRESN and SCSTRESU variables are not populated. And the reported Warnings occur only when SCTESTCD="ALTID" and SCSTRESC contains a numeric value.

I could send you the test dataset, to better illustrate the situation (the submit form however does not allow me to do so).

And what do you mean by "If you do not collect those data, you should not create these variables in SC domain."? The variables that are not populated can be excluded from define.xml and from sc.xpt? Isn't SEND specifying that all SEND variables that correspond to a domain in SEND specs should be present in the submitted .xpt?

 

s Sergiy
on April 5, 2012

Thanks. I see now. 

Those checks are programmed as a "Required" type, which triggers the checks execution even in a case if the involved variable is not in a dataset.

Therefore your initial comment is completely valid. There are several options to fix the issue, and your proposal is the most simple and easy way. Let us think about this. We will do some additional research on real data before a final decission. Anyway it is expected to be fixed in the next release of the tool.

As a temparary solution for your company internal business process you can switch the execution of those checks by the following changes in "config-send-3.0.xml" flie:

1. Open the file by any text editor

2. Do search/find "sc.xpt"

3. under  <def:leaf ID="Location.SC" xlink:href="sc.xpt"> line you will see the list of rules assigned to SC domain.

4. under  <!-- Findings Domain Rules --> section find the rules you need and change Active="Yes" to Active="No"

e.g., <val:ValidationRuleRef RuleID="SD0026" Active="Yes"/> to <val:ValidationRuleRef RuleID="SD0026" Active="No"/>

5. Save your changes in the document

______________________________________________

SEND IG v3. Section 2.3 (page 12):

"As long as no data were collected for Permissible variables (see Section 4.1.3), a sponsor is free to drop them from the domain model, and the corresponding descriptions from the data definition file. New variables (other than those that are from the same general observation class) must not be added, and existing variables must not be renamed or modified for novel usage. "

 

 

 

b Bedeoan
on April 5, 2012

Thank you again for your valuable feedback, sergiy !

 

b Bedeoan
on May 28, 2012

I feel that the following rule should be disabled for PM:

SD0026: "Missing value for --ORRESU, when --ORRES is provided".

PMORRES can be populated while PMORRESU remains empty - see example from SENDIGv3.pdf - page 118.

 

Want a demo?

Let’s Talk.

We're eager to share and ready to listen.

Cookie Policy

Pinnacle 21 uses cookies to make our site easier for you to use. By continuing to use this website, you agree to our use of cookies. For more info visit our Privacy Policy.