When testing the latest version (2023-11-15) for implementation in the open source "Smart Submission Dataset Viewer" I got some validation violations for CORE-000289 (CG0181) and CORE-000290 (CG0183), which i.m.o. are false positives.
I think the reason is that the implementation of the wording "for continuous measurements" is incorrect. The current implementation checks whether the value of LBORRES is a (floating point) number by a regular expression "^-?(0|[1-9]\d*)(.\d+)?$".
However, a regular expression cannot be used to find out whether it is a "continuous measurement". The only way this can be done is by the LOINC code (using a RESTful Web Service it can be found out whether the "scale" of the test is "Qn" - Quantitative, or not), or by LBRSLSCL (result scale), which unfortunately, was introduced in SDTM 15 years too late.
So, I get false positives when LBORRES has values like "<40" (see screenshot), ".94", ...
I think the damage can somewhat be diminished by adapting the regular expression by:
not requiring that there is a character before the decimal point (so that as well "0.94" as ".94" are accepted)
allowing that the first character is either "<" or ">", which are used often to indicate "below" and "above".
But, once again, CDISC should, after over 15 years, really start realizing that the LOINC code is the only real identifier of a test ...
When testing the latest version (2023-11-15) for implementation in the open source "Smart Submission Dataset Viewer" I got some validation violations for CORE-000289 (CG0181) and CORE-000290 (CG0183), which i.m.o. are false positives. I think the reason is that the implementation of the wording "for continuous measurements" is incorrect. The current implementation checks whether the value of LBORRES is a (floating point) number by a regular expression "^-?(0|[1-9]\d*)(.\d+)?$". However, a regular expression cannot be used to find out whether it is a "continuous measurement". The only way this can be done is by the LOINC code (using a RESTful Web Service it can be found out whether the "scale" of the test is "Qn" - Quantitative, or not), or by LBRSLSCL (result scale), which unfortunately, was introduced in SDTM 15 years too late. So, I get false positives when LBORRES has values like "<40" (see screenshot), ".94", ...
I think the damage can somewhat be diminished by adapting the regular expression by:
But, once again, CDISC should, after over 15 years, really start realizing that the LOINC code is the only real identifier of a test ...