1777 Sentry Parkway West
Building 17, Suite 405
Blue Bell, PA 19422
+1 (888) 507-2270
AD0033 - AD0036 rules
SergiyThis is a quite complicated issue in validation implementation
Hi Yasutaka,
This is a quite complicated issue in implementation of validation engine.
P21 Validator compiles a check code only for variables which both 1. exist in a dataset and 2. were explicitly defined in the P21 standard specs.
AD0034 rule (*PFL value is not Y or null) is implemented according to ADaM conformance rules from CDISC team. However, *PFL (Parameter Level Flag) variable is not included into BDS specifications of CDISC ADaM-IG 1.0 standard. Therefore, when 1511.6 engine compiles executable checks for BDS datasets, AD0034 is not created. The same is true for AD0034, AD0035 and AD0036 rules.
ADaM standard specifications in 1810.3 engine were extended with ADaM OTHER. See page 5 of https://www.lexjansen.com/pharmasug/2019/DS/PharmaSUG-2019-DS-319.pdf . To cover any non-standard variables in ADaM OTHER, we added <any variable> (defined by a star placeholder ADAMOTHER.*) in P21 specifications of ADaM-IG 1.0 standard. As a result, AD0034 check is compiled and executed for ADaM OTHER. However, it is still not compiled for BDS datasets for the same reason as described above.
Standard specifications for ADaM-IG 1.1 includes *FL variable in all datasets (ADSL, BDS, OCCDS, ADaM OTHER). A definition of *FL variable covers variables like *RFL, *PRF, compiles AD0033 and AD0034 checks for all datasets where they are applied.
Surprisingly, validation of ADaM-IG 1.1 data will not support AD0035 and AD0036 rules in any datasets expect ADaM OTHER. There is no formal definition of *FN, *RFN or *PFN variables in BDS structure.
All above is an example of false-negative validation results which are very rarely reported by our users. Unfortunately, almost nobody complains about undetected data issues.
Kind Regards,
Sergiy
Hi Sergiy, Thank you for…
Hi Sergiy,
Thank you for your quick response. I' wondering if you could give me further details of AD0034.
In the example in above, I mentioned that 2. ADaM v1.0 + PMDA Engine 1810.3: AD0034 is detected for ESPFL in 1, 2 datasets only (e.g., ADPCAE: ADaM Other). For ESPFL in other datasets including BDS, no Rejects for AD0034 are detected.
This means that AD0034 is NOT detected in other ADaM OTHER datasets. I understand the situation that AD0034 is not created for BDS datasets. However could you please tell me why AD0034 is created in some ADaM OTHER datasets, but not created in other ADaM OTHER datasets. Any additional specific rules for AD0034? In my cases, it seems that if dataset name is <=6 then AD0034 is created. However if dataset name is >6 chars then AD0034 is not created.
To change the validation rule to PMDA Engine 1810.3 from 1511.6, AD0033/34 etc is newly created. To keep the traceability *PFL should be modified in all datasets (e.g., *PFL is created in ADSL and copied to other data) but Pinnacle 21 v3.0.2 doesn't create these issue records in the summary report for some ADaM OTHER datasets.
Kind regards,
SergiyHi Yasutaka, One of the…
Hi Yasutaka,
One of the most important thing for PMDA submissions is to have consistency between your validation results and independent validaion performed by PMDA. ADaM validation by engines 1511.6 and 1811.3 are quite reliable in achieving consistency with PMDA. Existing implementation of PMDA validation rules will not be changed for a while. You need to comply with it.
If you still need to use extended Terminology for ESPFL variabke, then one simple solution would be to change a name of your variable to avoid a suffix *PFL. It is not clear why do you use Parameter Level Flag in ADaM OTHER dataset, while it is expected to be BDS-specific variable.
I am not sure about your example "dataset name is >6 chars then AD0034 is not created". Could you provide more details?
Thank you,
Sergiy
Hi Sergiy, Please ignore my…
Hi Sergiy,
Please ignore my comment: "dataset name is >6 chars then AD0034 is not created".
My question is just ... All ADaM OTHER datasets has *PFL variable unfortunately (as not parameter-flag) but P21 created AD0034 report for 1 or 2 datasets. This situation confuses us a little bit. I am not sure this is reproduced in your environment though.
Best,
Yasutaka
Hi,
Could you please tell me what is happened for AD0033 - AD0036 rules?
Or in which scenario rules (AD0033 - AD0036) will work in Pinnacle21 validator.
Here is one example of AD0034 case. This situation is occurred for many CRT packages and I think this example is also happened in other company.
Dataset;
> 20 ADaM datasets with BDS and ADaM Other (+ define.xml). All ADaM datasets have ESPFL variable with Y/N terminology.
Using Pinnacle Community v3.0.2;
1. ADaM v1.0 + PMDA Engine 1511.6: no Rejects are detected for AD0034
2. ADaM v1.0 + PMDA Engine 1810.3: AD0034 is detected for ESPFL in 1, 2 datasets only (e.g., ADPCAE: ADaM Other). For ESPFL in other datasets including BDS, no Rejects for AD0034 are detected.
3. ADaM v1.1 + FDA: AD0034 is detected for ESPFL in all datasets accurately (maybe?).
4. ADaM v1.0 + FDA: AD0034 is detected for ESPFL in 1, 2 datasets only (e.g., ADPCAE: ADaM Other). For ESPFL in other datasets with including BDS, no Errors for AD0034 are detected.
Using Pinnacle Community v2.1.3 and v2.2.0;
1. no Errors/Rejects of ESPFL for AD0034 are detected regardless of FDA and PMDA setting (?)
Similar question was posted in July 2019 and I am confident that I have same question.
https://www.pinnacle21.com/forum/ad0033-ad0036
If my understanding is correct, "A variable with a suffix of PFL has a value that is not Y or null" rule for BDS was included in ADaM IG v1.0 package (ADaM_validation_checks_v1.3_final.xlsx). So I think ADaM IG version difference and PMDA/FDA version setting are NOT an issue for this case.
Do I miss something of ADaM IG rule?
For using ADaM IG v1.2 package, we can find the sample ADaM datasets, adae, adqsadas and adsl. And rename the COMP24FL to xxxPFL for adqsadas (and in define.xml) then we can test it.
Thanks in Advance.