In March 2023, the PMDA published an updated version of its Validator Rules. Pinnacle 21 Principal Consultant Chikaaki Nakao delivered an overview of the differences between newly released version 4.0 and the now legacy version 3.0.
Note: Chikaaki Nakao is a Pinnacle 21 staff member and in no way speaks for the regulatory agencies or standards development organizations. His presentation was delivered on behalf of Pinnacle 21.
Drug development takes years, sometimes a decade or longer, before enough data has been collected, formatted, and validated to render a study ready for submission.
Once a sponsor has identified a target submission date, all studies included in the submission should be revalidated using a single PMDA engine. Studies completed in earlier phases should always be re-validated using one of the valid PMDA engines, as it is likely they were validated originally with an outdated engine.
Next, in the pre-NDA meeting, you’ll finalize the submission package and submission date.
Once the application is in the submission 'GATEWAY,' the PMDA runs the validation through their instance of Pinnacle 21 Enterprise using the engine specified by the sponsor.
PMDA review will not begin - or continue - if or when any of the following situations occur:
According to a recent PMDA presentation held in early March, ten applications were halted in the last twelve months. We’ve made some technical and process recommendations later in this article to help you sidestep issues that might delay submission review for your organization.
During review, the PMDA may require that a sponsor fix the Reviewer’s Guide or submitted files if any 'Error' issue is not explained or if a new issue is found during PMDA validation.
On the PMDA website, you’ll find four helpful documents relating to e-data submission, as well as the standards catalog and validation rules.
The document structure has not changed since the release of PMDA Validation Rules 3.0.
Currently, there are four versions of PMDA validation rules. A sponsor will choose one single version for an application. If an application date is between the start and end dates of a particular engine, you may select it. Keep in mind that you should always revalidate data before submission if you change the engine selection.
Engine 1511.6 is already retired/deprecated and should not be used for any new application. It is still available for sponsors who may have used it for a previous submission while this engine was valid.
In addition, the v2.0 engine 1810.3 is also now deprecated as of March 31, 2023. As with Validator Rules v1.0, sponsors cannot choose this engine for new submissions.
Typically, each PMDA validation engine remains on the list for four to five years.
Technically, you can choose different engines to validate each data package in your study, but when it is time for submission, sponsors must choose a single engine for all studies – and therefore data packages – in the application.
While it is always recommended to use the most recent version of any agency engine for submission, there may be cases in which continuing to use a legacy engine is appropriate. For PMDA 2010.2, Enterprise users can simply choose PMDA 2010.2 (legacy). For environments with the new PMDA 2211.0 already deployed, this engine selection will have been made automatically with the update.
It is important to note that as of the end of March 2023, PMDA legacy engine 1810.3 is no longer acceptable for new submissions.
The Reviewer's guide should be updated using the new engine if the engine used during validation is no longer listed as a valid engine on the planned submission date. For define.xml and xport files, they should be updated only when they have 'Reject' issues. Minimal change should be given to define.xml and datasets.
A major change in PMDA Validator Rules v4.0 is the support of SDTM IG v3.3, as well as the removal of support of Define.xml 1.0. See below:
In a March 2023 PMDA webinar, mentioned there was some consideration of implementation of SDTM IG v3.4 in a future release. While SDTM IG 3.3 is included in 2211.0, there are no tentative dates or firm plans for this update, and it is not currently listed in the Data Standards catalog. However, SDTM IG 3.4 is supported by the current P21 engine, 2204.0, so validating ongoing studies using that engine can help you identify and resolve issues related to SDTM IG 3.4.
PMDA 2211.0 only supports Define 2.0. It is the first of the PMDA engines that does not support Define 1.0, and while there are plans to add support of Define 2.1 to a future PMDA engine, this new version does not incorporate considerations for Define 2.1. As such, if you used Define 2.1, you would trigger an issue.
The new PMDA rules are not available in the current P21 engine, but we expect the next engine update to include any additions in PMDA Validator Rules v4.0. While a date has not yet been set for this P21 engine update, we do expect a new engine release in Q2 2023.
Along with the addition of 465 new rules for SDTM IG 3.3, there are a myriad of other changes as well. See the table below, and follow along in the webinar recording at the top of this article for more details:
Pinnacle 21 always recommends using the PMDA guidance as primary source of information when it comes to requirements for submitting eData and applications, but there are a few processes you can incorporate to make your submission and subsequent review easier.
These technical recommendations may help reduce the risk that submitted data is rejected at the PMDA GATEWAY:
The PMDA provides a wealth of information on electronic study data and the submission process. Refer to the documents listed in the figure below for help or contact the PMDA directly for guidance whenever you have questions about submissions.
Q: For clinical programs that span many years, is it expected to re-run P21 closer to submission to align the checks on all studies within the submission?
A: Yes. The reviewer's guide should be updated using the new engine if the engine used in validation is not listed as the valid engine on the planned submission date. For define.xml and xport files, they should be updated only when “Reject” issues occur. Minimal changes should be made to define.xml and datasets.
Q: Do study data and other esub documents from studies conducted by US subsidiaries need to be altered by Japanese colleagues for the SAS encoding issue?
A: No, if you already created datasets using specific encoding, you do not have to change it to something else. However, your colleagues in Japan need to know which encoding you used when you create xport files because they need to choose same encoding for opening xport file.
Q: Is the recommendation to use unicode is only for PMDA? The FDA seems to prefer pure ASCII.
A: Yes. PMDA wants to have pure ascii characters in datasets, too, and pure Ascii is a part of Unicode (UTF8). There is no pure ascii session encoding in SAS, so we recommend Unicode because it is used both upstream (EDC) in many cases as well as downstream (define.xml and P21 validation). You can avoid transcoding failure simply by using Unicode.
Q: Will PMDA accept SAS datasets in latin1 encoding?
A: PMDA would like to have pure ascii data; however, if the data contains only pure ascii characters, the SAS session encoding can be latin1.
Q: Can you clarify, what is the aCRF supposed to be labeled to avoid problems with PMDA?
A: If you would like to avoid issues with the validation results, please use 'acrf.pdf' as the file name.
If we missed any burning questions, check out the full webinar and slide deck to see if we covered it. If you still have other questions, please feel free to contact us!
Tags:
Blog Main Page