4 Radnor Corporate Center
Suite 350
Radnor, PA 19087
+1 (888) 507-2270
Rules FDAC154 and FDAC0169
Hi Jozef, SD0026/FDAC1054
Hi Jozef,
SD0026/FDAC1054 rule is a good example, when some false-positive errors are expected.
OpenCDISC team is continuously working on tuning the algorithm of the check. Now the following records are excluded:
- --ORRES = ''
- --ORRES is not numeric value
- --ORRES = '0'
- --ORRES is numeric value with preceding "+" sign. Like "+1", "+2"
- LBTESTCD is "PH" or "SPGRAV"
- LBTEST is some Antibody or Ratio tests
Few years ago PhUSE working group tried to figure out the best approach to handle missing units. Unfortunately we did not find a perfect solution. There are many ideas. The checks' algorithm is still under development.
Kind Regards,
Sergiy
Hi Sergiy
What do you mean by "The following records are excluded"? So they are not yet part of the validation checks?
So this means that I can still ignore the warning/error when LBTESTCD=PH and Std. Unit is missing, right? I have seen dataset where the unit of H+ concentration was entered just to remove those errors, but this is also not correct.
Best regards,
Manolya
Hi Manolya, It means that
Hi Manolya,
It means that the Validator considers LBTESTCD="PH" records as an exception for business rule to have units for numeric results. Checks SD0026 and SD0029 will not produce false-positive messages for pH tests.
If you still receive such messages for pH records then there is something wrong with your Validator. My only possible explanation is that you are using some "pre-historical" version of Validator.
Kind Regards,
Sergiy
cnsistency rules for LBORRES and LBORRESU
I wonder how such consistency rules are handled.
Take for example the test "glucose in urine by dipstick". Probably this means LBTESTCD=GLUC, LBSPEC=URINE and LBMETHOD=DIPSTICK.
If we now search for the LOINC codes for this combination, we find that there are as well quantitative tests for this combination (so a number is expected for LBORRES and LBORRESU contains a unit for a concentration either as mass/volume or as mole/volume), as well as qualitative tests (LBORRES is either POSITIVE or NEGATIVE, and LBORRESU is empty).
The only way I see this can be accomplished is by the use of web services taking the LOINC code (LBLOINC) and using UCUM on the server side (fortunately most, but not all, LB units are also present in UCUM).
Does OpenCDISC have any plans to implement such web services for consistency rules?
I was surprised to find, as well in the FDA worksheet as in the OpenCDISC implementation, rules FDAC0154 "Missing value for --ORRESU, when --ORRES is provided" and FDAC0169 "Missing value for --STRESU, when --STRESC is provided".
We all know that there are so many tests that have no unit. A simple example of an ORRESU for which there is no unit are "NEGATIVE" (many tests), or for the test "pH".
So this rule is ... damned wrong" (thanks FDA!). Similar for FDAC0169.
Fortunately, the OpenCDISC implementation seems to have realized this and I did not get any errors/warnings for my test files for many tests that have no units (the soup is not eaten as hot as it is served), except that I got one error FDAC0169 on several records, e.g. where ORRES=42.8, ORRESU=%, STRESC=0.43, STRESN=0.43, STRESU=null. In these cases, I think no warning should be thrown, as "0.43" is indeed dimensionless as it is a fraction.
I do understand the difficulty however, as many people would just copy the value of ORRES to STRESC in this case, and keep "%" for the standardized unit. I do realize that OpenCDISC is not using much valuelevel testing (although ...) but we should all start thinking about algorithms to prevent such false positives. In this case, the algorithm could state that when the ORRESU is % and the STRESC/STRESN is clearly different from the ORRES, no warning is thrown.
Isn't this the kind of features we would expect from SHARE?