l Lieke
on

 

Hi,

Validating the same Define-XML with the same settings, same SDTM CT version (2020-12-18), but with only the Data Standard differently (SDTM-IG 3.2 (FDA) versus (SDTM-IG 3.3 (FDA)) gives me different results.

  Settings Define-XML validation based on Data Standard SDTM-IG 3.3 (FDA):

Settings Define-XML validation based on Data Standard SDTM-IG 3.2 (FDA):

Settings Define-XML validation based on Data Standard SDTM-IG 3.3 (FDA):

Settings Define-XML validation based on Data Standard SDTM-IG 3.3 (FDA)

When using the Data Standard SDTM-IG 3.2 (FDA) I don't get any issues related to "DD0029-Required attribute def:ExtendedValue is missing or empty", while if I validate the Define-XML using SDTM-IG 3.3 (FDA) I do get issues related to "DD0029-Required attribute def:ExtendedValue is missing or empty", see image below:

The issues that appear when I validate the Define-XML based on SDTM-IG 3.3.

These units however do exist in the codelist Unit and hence these are not extended values. This is also correctly displayed in the Define-XML as the codes have been provided:

Codelist unit

Could anyone explain to me why validating the Define-XML using SDTM-IG 3.3 gives me those issues? And why these do not appear when I validate it using SDTM-IG 3.2?

Thanks,

Lieke

 

Forums: Define.xml

Sergiy
on November 3, 2021

Hi Lieke. 

Could you provide a list of variables which utilize (UNIT) codelist in your define.xml file?

Thank you,
Sergiy

 

l Lieke
on November 5, 2021

Hi Sergiy,

 

The following variables make use of the codelist UNIT:

Variables utilising CL.UNIT

Best regards,

Lieke

j Jozef
on November 6, 2021

The question to supply the list of variables that use the codelist, is very surprising, as whether a value is "extended" or not (i.e. present in the CDISC codelist) is essentially independent of the variable to which is applied.
Or it must be that behind the scenes in the validator, subset codelists are used, that do depend of the domain/variable.
Setting up subset codelists is however always the task/responsibility of the sponsor, and surely not of the validating software.

Jozef Aerts
CDISC Define-XML Development Team

 

l Lieke
on December 17, 2021

Hi Sergiy,

 

I was wondering if you have any thoughts on the issue raised. The requested codelist is available.

 

Thank you in advance!

 

Best regards,

Lieke

Sergiy
on December 17, 2021

Hi Lieke, 

In SDTM-IG 3.3, CT codelist for PCSTRSU variable is (PKUNIT). Validation is performed according to CDISC documentation. Reported terms are extensions of (PKUNIT) codelist. You utilized incorrect CT codelist for PCSTRESU variable in SDTM-IG 3.3.

In SDTM-IG 3.2, CT codelist for PCSTRESU is (UNIT). Therefore, you do have validation errors.

Kind Regards,
Sergiy

 

j Jozef
on December 18, 2021

This case poses an interesting question ...
When one adds an existing CDISC-CT unit from the UNIT codelist to the codelist of PKUNIT, is that than an "extended" value?
On first sight, yes, as that unit is not in the PKUNIT, but on the other hand, it IS a valid CDISC unit, and does have a CDISC-NCI code ...
But I do agree with Sergiy that strictly spoken, it should be regarded as "extended" when added to PKUNIT. Curious is then that one then needs to remove the NCI code (from the Alias) from that entry in the PKUNIT codelist.

That CDISC still sticks to its own coding system for units, that even does not allow for simple unit conversions, is a sign of poverty for CDISC. The rest of the world (including the medical world) is using UCUM notation (https://ucum.org/), which allows automated unit conversions, even between conventional and SI units, as e.g. has been implemented in the NLM RESTful web services (https://ucum.nlm.nih.gov/ucum-service.html).

But yes, UCUM, as well as SNOMED and LOINC are still "not invented here" at CDISC ...

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.