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.
PMDA Submission Process Overview
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.
When might a PMDA review be halted?
PMDA review will not begin - or continue - if or when any of the following situations occur:
Anytime a “Reject” issue is found
Validation fails due to a problem with the submitted files
If a validation report is not created
If the selected Validation Rules version on Form A differs from GATEWAY
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.
Where are the new PMDA Validator Rules?
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.
The basics of PMDA engines
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.
Choosing the right PMDA validation engine
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.
When to update the Reviewer’s Guide
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.
Which standards are supported by 2211.0?
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:
What about SDTM IG v3.4?
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.
What about Define.xml 2.1?
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.
What about Pinnacle 21’s engine?
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.
What changed from PMDA 2010.4 to PMDA 2211.0?
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:
Process Recommendations
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.
Fix ALL Reject issues. Your review will not proceed when Reject issues are present.
Once the submission date is scheduled, check to ensure you are using the same version of the validation rules for the entire application.
Use the most recent version of the standard in the new PMDA engine 2211.0 if your submission date has not yet been determined.
Technical Recommendations
These technical recommendations may help reduce the risk that submitted data is rejected at the PMDA GATEWAY:
The SAS CPORT procedure does not create xport v5 format, so even if the file extension is ”xpt”, CPORT procedure will only create a cport file. To create the .xpt file, use the data step, copy procedure, or an autocall macro.
Use the same file name and dataset name for xport files; the filename statement and data step should have same dataset name.
Please use Unicode as SAS session encoding. As a system requirement, an xport file can be opened with encoding A when the file is created with encoding A. If you are using the local default encoding, it would not be available outside of your country. In addition, the EDC database is usually Unicode, define.xml is in Unicode, and the validation session uses Unicode.
Update “Standard Version” in define.xml to the one selected during validation. For example, you are submitting using ADaM 1.2 to the FDA, but you are downgrading the ADaM standard to v1.1 in PMDA submission. It is important to update the standard version in define.xml. Since the PMDA runs validation dynamically using define.xml and tsv file information, the standard version must be same as the one used during validation in the UI.
Revalidate all files with Pinnacle 21 software when file or file name is updated. Often, files are not validated after filenames or define.xml are updated, and this can lead to errors and confusion during review.
Where to find more information
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.
Questions and Answers
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.