Those are not duplicates, but separate codelists for validation needs.
CDISC CT is a source of standard terms which usage is defined in SDTM/SEND/ADaM Implementation Guides.
For example, CDISC SDTM CT Codelist ‘No Yes Response’ (C66742) includes 4 terms. However, some Flag variables like --BLFL, DTHFL, --PRESP, --DRVFL, --EXCFL may be populated using only a single term ‘Y’. Therefore, P21 CT files have a separate extension Codelist ‘No Yes Response (Yes Only)’ with a single term ‘Y’.
Another example is a Codelist ‘No Yes Response Code’ which includes NCI Codes instead of Terms for validation of some Value Level items in TSVALCD variable of TS domain.
(TSVALNF) is another, but quite different example of CDISC SDTM CT extension for validation.
SDTM IG 3.1.3 introduced TSVALNF variable and provided its reference to (NULLFLAVOR) CT Codelist. However, 7 years later there is still not such codelist in CDISC SDTM CT.
For validation purpose, Pinnacle 21 team added (TSVALNF) codelist based on HL7 to original CDISC CT files. NCI Codes were populated for terms which exist in other NCI Controlled Terminologies.
The reason that CDISC did not publish a “NULLFLAVOR” codelist is obvious: even within HL7, this list is highly disputed. For example it contains “PINF – positive infinite”. “Infinite” being a “flavor of null”? Are you kidding? I learned differently at primary school.
IF you want to use a “null flavor” codelist, then you should create your own one and assign it to the variable in the define.xml (“CodeListRef”). You can of course use the values from HL7, but this is not absolutely necessary. The validation software MUST then pick up the codelist from your define.xml, and use yours for the validation, as the define.xml is “the sponsor’s truth about the metadata”. It should not be up to a software vendor to decide what to use for such an even not published codelist.
What I also find frightening from Ravish’s screenshot is that NCI codes have been added to the items. Where do these come from? It is only up to CDISC and NCI to assign NCI codes and to publish them.
With best regards,
Jozef Aerts
Prof.Med.Inf. and CDISC and HL7 volunteer.
Sergey wrote that NCI Codes were populated for terms which exist in other NCI CTs. In RG we need to write which CTs were used for the submission, so we need to specify which CT the “Parameter Null Flavor” codelist was taken from.
P21 team, could you please help to understand if there is any other non-SDTM CDISC/NCI CT which has this codelist? I could not find it among any non-SDTM CDISC/NCI CTs.
As per Define-XML specification we are allowed to use CDISC/NCI CTs and not non-CDISC/NCI CTs. The Alias element Name attribute has the following description:
“As a child element of a CodeListItem or EnumeratedItem, when Context=”nci:ExtCodeID”: C-Code for corresponding CDISC Controlled Terminology Term.”
In general, all of this discussion is some kind of legacy stuff.
For example, an extended codelist for validation of Null Flavor variable was introduced more than 6 years ago. NCI Codes were taken from HL7 terminology in NCI system. NCI Codes are the same for all terms which are synonyms across different codelists and different terminologies. That time, an assumption was that Null Flavor is a new concept in SDTM standard and CDISC will add a codelist for it soon. There were also few other similar extension codelists like “Mood”.
Later, CDISC clarified that Null Flavor is ISO 21090 format. Therefore, there is no need for CDISC Codelist. Pinnacle 21 team adjusted existing rules (new SD2283) and configuration files. Issue does not exist anymore.
However, there are several things you need to be aware about.
Use of (TSVALNF) codelist was stopped in engine 1907.0. All previous versions are affected by this bug.
For PMDA submissions, users must utilize validation engines as requested by the Agency. It means that both 1511.6 and 1810.3 engines include old implementation of a codelist/format for TSVALNF variable and will generate false-positive messages in some cases. Nevertheless, according to PMDA guidance, users must present and explain all reported validation messages including software bugs.
While new engines do not use (TSVALNF) codelist, we need to keep it in our CT files to support older versions of validator. It’s important for PMDA engines
