y Yawei
on

 

Dear all,

I have a question about SD1212: --STRESN does not equal --STRESC.

I validated my SDTMdata using Pinnacle 21 community ver. 2.1.3 and 2.2.0. (Configuration SDTM3.2(PMDA))

 

The SD1212 message was occurred

PPSTRESN, PPSTRESC 0.6079745, 0.607974498

SD1212: PPSTRESN does not equal PPSTRESC

 

However, these data are the same in SASdata.

My data:

PPSTRESN, PPSTRESC 0.607974498, 0.607974498

 

I investigated various dummy data.

I found this Error occurred when the value of 7th-9th decimal place is between 495 and 499. (For example 0.000000495-0.000000499)

May I ask if you have any suggestion? Any feedback or any advice on this topic would be appreciated.

Forums: SDTM

j Jozef
on April 21, 2017

The reason behind this is that SAS Transport V ("XPT") is a very old format (30 years!) from the mainframe time. It was developed for allowing to exchange SAS data sets between IBM mainframes and VAX computers (only to be found in musea nowadays). The problem is that the binary presentation of numeric values is completely different from the one modern computers are using. The result is that there is an inherent uncertainty (lack of precision) when you have many decimal places when reading the old representation with a modern computer language like Java.
In my own software, I implemented this so that an error is only generated when the two values differ by more than 0.001% or so. I do however not know how this has been implemented in the Pinnacle21 validator.
And the FDA is still refusing to accept Dataset-XML ... :-(

y Yawei
on April 25, 2017

Hi  XML4Pharma,

 Thank you for your answer.

 What a pity there's been no solution yet.

 Therefore, we are going to explain what happened in the Study Data Reviewer's Guide

and just remain the error(SD1212) .

 If you have some other suggestions, I would be appreciate hearing from you.

Best regards,

vivi

 

 

l Lex
on April 25, 2017

@Jozef This specific issue would not be solved by Dataset-XML though, as we saw in the FDA Dataset-XML pilot, since that format would not have an exact representation of floating point data. I think in this case the Define-XML document needs to define the significant digits.

j Jozef
on May 3, 2017

@Lex: I completely agree.
This is also how the XPT2DatasetXML software works (freely available from SourceForge at: https://sourceforge.net/projects/smart-sds-xml-viewer/files/ )
When transforming numeric values from XPT files, the software looks into the define.xml to find out whether the value is either an integer or a float, and in the latter case looks up what the definined precision is (@SignificantDigits attribute), and "rounds" the value according to that information.
For example, when the direct translation (from XPT-IBM format) is "5.00000001" (although you see "5" in the XPT viewer), and the define.xml states that this is a float with @SignificantDigits (which is a misleading wording, as it defines the precision after the decimal point) = 3, then the value "5.000" will appear in the Dataset-XML data point.
 

s subhash
on July 21, 2021

Hi All,

I have faced the similar issue in PP domain recently. Let me know if there is any update to be done. As per the previous comments looks like there is an issue.

 

Thanks,

Subhash

j Jozef
on July 22, 2021

There is no solution for this, except for finally getting rid of SAS Transport 5 and moving to modern formats like XML, JSON, Turtle-RDF.
A "workaround" can be e.g. to check whether the values differ by more that 0.001% or so, or use the "SignificantDigits" from the define.xml.

When one thinks a bit further, why should the same information be provided twice (data redundancy in -STRESC and -STRESN)?
Right, ONLY because of the mandated use of outdated SAS Transport 5 ...

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.