ExtendedValue issue when validating Define-XML only using standard SDTM-IG 3.3, but not when validating it using SDTM-IG 3.2

Sergiy

on November 3, 2021

P21

Hi Lieke.  Could you…

Hi Lieke. 

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

Thank you,
Sergiy

Hi Sergiy,   The following…

Hi Sergiy,

The following variables make use of the codelist UNIT:

Best regards,

Lieke

ExtendedValue issue when validating Define-XML ...

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

Hi Sergiy,   I was…

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

P21

In SDTM-IG 3.3, CT codelist for PCSTRSU variable is (PKUNIT)

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

ExtendedValue issue when validating Define-XML ...

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 ...