SD1029 - Extended Ascii not allowed - Where is the regulatory requirement for this?

Hi! Currently the check

Hi!

Currently the check SD1029 is limited to SDTM variables, which can be used as variable names or labels (--TEST, --QLABEL, --PARM, --TESTCD, QNAM, --PARMCD). It was introduced t avoid any potential problems with data transposing in any applications.

I do not know any regulatory requirements to justify this data quality check, but from my personal experience I would like to have it a while ago.

Regards, 

Sergiy

SD1029

Thanks Sergiy. I didn't realize this check was only for a small list of variables. That makes sense now.

SD1029 not limited?

Hi Sergiy, we've experienced with the OpenCDISC version 1.3 that also for example the following variables are checked for non-ascii characters and therefore giving errors: CMTRT, AETERM, INVNAM, QVAL

It's not possible to have no non-ascii characters in those fields as most of them are freetext fields and non-ascii characters are very common like in the Investigator Names. So do you know if and when there's any restriction to be added as you've posted above?

best regards,

Christina

The check hits more variables than the select few

Like Christina, I find also the check is picking up on characters outside the ascii range for variables like LBNAM, AETERM, etc.  It is not limited to the fields that would be transposed.

Thanks very much.

Regards,

Joan

Hi! The official release of

Hi!

The official release of the version 1.3 was on March, 31st. May be you use an early "pre-official" draft version, which could be available for download before those date.

Could you re-download the validator package to ensure that the issue still exists?

Thank you, 

Sergiy

downloaded Apr. 9

I re-downloaded it after the pre-official one.  So the problem persists.  Thanks.

- Joan

Could you send me your

Could you send me your "config-sdtm-3.1.2.xml" file from the "opencdisc-validator\config" folder?

Thanks, 

Sergiy

sergiy () opencdisc.org

Not needed?

I don't think this check is needed for the free-text variables that forum user "christina kramarsch" mentions earlier. For example, some verabatim term for medicine includes a word with a grave accent and this is non-ASCII - thus it flags as an error in the OpenCDISC report - thus, when the FDA will see it, and thus we (as sponsor) will need to explain the error in the supplemental definitions document.

Personally, I think it would be cleaner to remove this check from these type of variables.

WebSDM

Some older versions of WebSDM, one of the first thing it did was to transpose the supplemental qualifiers in the SUPPQUAL datasets and applied them back to the parent domains. This step would fail when QNAM contains non-ASCII characters. If my memory serves me correctly, this was remediated by supporting Unicode.

Data in foreign languages should also be translated in English for U.S. FDA submission, where appropriate.

That said, to avoid issues in other data review tools at the Agency, I like this check to be run non-discriminatorily so I can evaluate if anything needs corrective action.

I agree with Anthony, that

I agree with Anthony, that the rule should exist, but Severity may be reduced to 'Warning'.

The variables involved in the check are only *TEST,*TESTCD,QNAM,QLABEL, *PARMCD, and *PARM.

I disagree

I disagree that this rule should exits - it is just like saying: "we do not allow more than 80 characters in a record, because we are still using punchcards".

In my case, OpenCDISC protested on the character "µ" (micro). I can barely imagine that modern software cannot handle this character. But maybe the FDA's software is not modern.

Like in another of my contribution, I would say that this is not a data issue, it is a software issue. Any modern software can handle unicode, so why is this rule still existing? In any other industry, it would already have been abandoned for a long long time.