Error of The Origin Type attribute "Derived"

What version of validator do you refer to?

Hi Yuta, 

What version of validator do you refer to?

Thanks, 

Sergiy

Re: What version of validator do you refer to?

Hi Sergiy,

Thank you for asking.

I confirmed the error when I used the Pinnacle21 Community Validator v3.0.1 and v3.0.2.

Thank you.

 

-Yuta

def:Origin "Derived"

XML (and thus also define.xml) is case sensitive!
This is often not recognized by people who are used to outdated XPT. Unfortunately, the SEND-IGs did it wrong, not understanding the case sensitiveness of XML. This has now been repaired by having representatives of the SEND team in the Define-XML team.
This is also reflected in the Define-XML 2.1 where the values are "Collected", "Derived", "Assigned", "Protocol", "Not Available" and "Predecessor". The latter will (usually) not be used for SEND.

So, it really must be "Derived", and not "DERIVED".

A temporary solution (but not a clean one) for validation programs might be to accept both, the full uppercase one ("DERIVED") and the correct one ("Derived"), but only in the case of SEND.

 

Not an issue in P21C 3.x. Ensure correct validation set-up

Hi Yuta, 

DD0073 (Invalid Origin Type value) issue should not be reported in P21 Community 3.x when validating Define.xml file for SEND data.

See Description of DD0073 in the "Rules" tab of your validation report.

Please ensure that you correctly selected Data Standard of your Define.xml file during validation set-up.

Kind Regards, 

Sergiy  

Please ensure that  def:StandardName="SEND-IG"

Another case could be incorrect data standard info in your Define.xml file.

Open it with any text editor and ensure that a value for def:StandardName attribute is "SEND-IG".

Here is an example:

 <MetaDataVersion OID="MDV..SEND-IG.3.1" Name="Study null Data Definitions"
                       def:DefineVersion="2.0.0"
                       def:StandardName="SEND-IG"
                       def:StandardVersion="3.1">

See details at https://www.pharmasug.org/proceedings/2018/SS/PharmaSUG-2018-SS14.pdf

Kind Regards, 

Sergiy

 

See Define-XML Errata. I was surprised too

Hi Jozef, 

Unfortunately, it is not an error in SEND-IG. Formally, it's otherwise.

New SEND-specific terms like "DERIVED" were added as Errata to Define-XML v2.0 standard. It looks like an acknowledgment of correct SEND IG and incorrect Define-XML standard specs. See https://wiki.cdisc.org/display/CDISCKIE/Define-XML+2.0+Errata

Therefore, this is a question for developers of Define-XML standard. 

Kind Regards,

Sergiy

Define-XML errata

Hi Sergiy,

You are right about the errata - but it was NOT an acknowledgement of correct SEND-IG. It was mostly an emergency "rescue" measure.
Also, the define-xml team cannot be blamed when other teams do not correctly implement define-XML (and did not discuss this with the define-XML team at that time either). The situation has been considerably improved since then, and SEND people were heavily involved in the development of v.2.1.

I am confused about relation…

I am confused about relation of SEND-IG to Define-XML standard. It should be Errata for SEND-IG to be compliant with Define-XML instead of distortion of Define-XML standard.

Configuration of P21 Community and define.xml

Hi Sergiy,

Thank you for reply. When validating Define.xml file for SEND data by P21 Community 3.0.2, I select the Engine, Standard and Data Type below.

(When I select "SEND" for Standard, this issue does not occur)

 

 

 

However, there are DD0073 (Invalid Origin Type value)  in the "Rules" tab of my validation report below.

(I think that the description '..."DERIVED"... for SEND data' in below table is not correct. As Jozef mentioned, also "Derived" should be included for SEND data at least)

And def:StandardName attribute is "SEND-IG" as below.

And Issue Summary Tab is below.

 

 

Is my configuration of P21 Community v3.x and Define.xml correct?

Best Regards,

-Yuta

 

 

SEND-IG and Define-XML standard

Hi Jozef and Sergiy,

Thank you for discussion. I hope appropriate integration between SEND-IG and Define-XML standard.

-Yuta

Regarding question and answer in the blog

Hi,

Regarding the below answer in this site blog, the Pinnacle21 fires "Error" for "Derived", but not "Warning".  Should the "Error" modify to "Warning", fired by pinnacle 21?

And I am still wondering which document has priority, the SENDIG or the Define-XML v2.0 specification, when we prepare a define.xml for submission to the FDA. Does below answer means that the SENDIG should have priority than the Define-XML v2.0 specification? (Should ”Derived” be allowed to be included in define.xml even in SEND because the recently published Define-XML Terminology only contains "Derived"?)

 

 

 

 

-Yuta

Hi Yuta,  Could you clarify…

Hi Yuta, 

Could you clarify what version of Validator you refer to? The issues discussed above are historical and most of them do not exist anymore in current versions of Validator.

Information in blog post is not complete. SEND-specific origin "DERIVED" is a part of Errata for Define-XML 2.0 documentation. I believe that SEND-IG should be fixed to be consistent with Define-XML standard instead of adding a confusing patch to Define-XML. Unfortunately, it is not a case. 

Kind Regards,
Sergiy

 

Hi Sergiy, Thank you for…

Hi Sergiy,

Thank you for your reply. I use pinnacle21 community version=3.0.2 and validation engine version=1903.1 (Please see my screen shot below). My pinnacle 21 has fired "ERROR" of pinnacle21 ID=DD0073 for "Derived" in define.xml for SEND data yet.

If the information in blog post is not complete, could you please modify it? It is seemed that the above answer on the blog may misleads the CDISC community.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Best regards,

-Yuta

Unfortunately, this is a correct validation message

Hi Yuta, 

Unfortunately, this is a correct validation message. A correct value in SEND is "DERIVED", not "Derived". I agree, that it looks unbelievably stupid. But now it's a part of CDISC Define-XML v2.0 standard (see Errata on CDISC wiki).

Kind Regards, 

Sergiy

Hi Sergiy,Thank you for…

Hi Sergiy,

Thank you for your reply. I understand your answer as below. It may be better that the answer in the blog will be modified to below because "ERROR" of pinnacle 21 is based on the errata in CDISC wiki, not SENDIG.

1. The Define-XML v2.0 specification should generally take priority over SENDIG when a define.xml is created.
2. However, an errata of the Define-XML v2.0 specification, which explains to use "DERIVED" for SEND data, is in the CDISC wiki. 
3. So, pinnacle21 has fired "ERROR" for "Derived" based on the errata.

I would like to clarify a position of erratas in the CDISC wiki. Is my understanding correct that erratas in CDISC wiki should be complied in addition to CDISC standards when SEND data packages is prepared? If you know any documents or any descriptions to explain that, I would appreciate it if you could let me know. 

Best regards,

-Yuta

Error of The Origin Type attribute "Derived"

The discrepancy between SENDIG and define.xml has been due to lack of communication between the two CDISC development teams, many years ago. This has now been repaired. Also the issue of "Derived" versus "DERIVED" has been repaired in Define-XML 2.1 which will soon be accepted by the FDA. From the 2.1 specification:
"In advance of CDISC publication of controlled terminology, the terms in the following tables can be used. Note that not all terms are applicable to all dataset types.
These terms, and the terms published in CDISC Terminology, supersede terms which have been defined in other CDISC implementation guides."

The latest CDISC Controlled Terminology containing Define-XML-CT (2020-03-27) contains the values "Assigned", "Collected", "Derived", "Not Available", "Predecessor", "Protocol", no complete-uppercase values.

Also, one can interprete the "Errate" in two ways: one way can be that ONLY the uppercase values are allowed for SEND in the case of a regulatory submission, the other way that besides the values listed in the Define-XML 2.0 specification, ALSO the uppercase values are allowed.

Also, I have not seen yet (but I can be wrong) a single FDA publication yet that says that only uppercase "DERIVED" is allowed.

At the moment, FDA is barely (or not at all) using the machine-readable capabilities of Define-XML. All the reviewers do is to use the VIEW of the define.xml in the browser. If someone can point me to a publication or official presentation of the FDA, I will revise that statement. In the browser view, the semantic meanings of "Derived" and "DERIVED" are completely the same, so what are we discussing here?

What does this mean for validation? I.m.o. setting ERROR status for "Derived" in the case of SEND is complete overkill. So, I propose that at least for the Community version (we, the users, are the community) to set the status to WARNING in case of "Derived" with the message that "uppercase DERIVED is preferred". Alternatively (which is in the spirit of all of the above), allow both "Derived" and "DERIVED".

With best regards,

Jozef Aerts
Member of (but NOT speaking on behalf of) the Define-XML development team and Define-XML Conformance team

Derived and DERIVED

Let me just add what I remember from the discussion around this issue in the Define-XML Dev team. We were getting signals that there were SEND submissions who did not want to use Define-XML v2, because there was the notion that it did not support SEND, the reason being the values mentioned in the SEND-IG not allowed by Define-XML v2.

This meant that just because of that reason there were SEND submissions that did not use the much improved version2 of Define-XML. For this reason we added the uppercase versions of the terms as an erratum to the origin type codelist. These uppercase values could only be used in a SEND submission. This was a stopgap solution that nobody really liked, but at least it encouraged wider adoption of Define-XML v2 in the SEND community. And also, we were already working on Define-XML 2.1 - with SEND representation part of the dev team - where this issue would be fixed.
Now let’s move on.

Lex - speaking on behalf of myself, not the Define-XML dev. team

 

 

Hi Jozef, Lex and Sergiy, …

Hi Jozef, Lex and Sergiy,

Thank you for the comments. I am happy to let me know the back story in the CDISC. As Jozef mentioned, everyone know that only "Derived" will be able to be used from Define-XML v2.1 based on Define-XML Terminology issued recently. So, I also think that it is better that "Derived" in addition to "DERIVED" can be used even in Define-XML v2.0 as of now for integration between v2.0 and v2.1 in the future. 

And I think a position of errata is ambiguous. It is seemed that it is difficult for CDISC users to find errata in CDISC wiki and some users, including me, are wondering whether the FDA has mandated errata in addition to the CDISC standards. I would like the FDA, the CDISC and the pinnacle21 to accurately explain a position of errata and how to judge to use "Derived" and/or "DERIVED" for Define-XML v2.1 in any documents (at first, in the blog in this site).

And also I hope that we can move to Define-XML v2.1 as soon as possible. Thank you again for your informative comments.

Best regards,

-Yuta