Periodic Adverse Drug Experience Report (PADER) is a part of post-marketing cumulative safety reports that need to be submitted to the United States Food and Drug Administration (US FDA). It provides a brief summary of changing post-approval AE profiles and safety information of an approved drug along with the benefit-risk profile evaluation.
The Oracle Argus Safety system has a native report named NDA, which helps in extracting cases as a line listing required for the PADER report (for regulatory requirements of a complete PADER, please click here). This report includes a Tabulation by System Organ Class (SOC) for all reported events that provide events and cases count by seriousness and listedness. See Figure 1.
So, how can a simple straight forward native Argus report generate so much anxiety and confusion over numbers?
Alexia is generating the draft data for this year’s PADER and has a rough idea of the number of cases and AEs. However, the group reviewing the data find count discrepancies two days before DLP. What happened?
Assume there exists a case in Argus with event seriousness marked as Serious and listedness as Listed. The case was expedited, and a 15-day report was submitted to US FDA during the PADER period. Post 15-day report submission, the case was unlocked to modify the listedness of the event from Listed to Unlisted as a follow-up. However, the case did not require resubmission to FDA. The PADER when executed in Argus, displays the count of the event under Serious Listed column. What Happened? The case is supposed to be Serious and Unlisted? The count of the event is still displayed under Serious Listed column. Not time to panic.
There are 14 non-serious cases with the AE term “emesis,” 8 are listed, and 6 are unlisted. What happened?
Case 1 has 2 events: Nausea and Vomiting
Case 2 has 3 events: Diarrhoea, Flatulence, and Vomiting
………………………………………………..|…Total Events…|…Total Cases
How Artificial Intelligence Can Enhance the Clinical Data Review and Cleaning Process
This guide analyzes how artificial intelligence – including machine learning – can be used by pharmaceutical and medical device companies to improve the clinical data review and cleansing process.
I don’t understand the Total Event and Total Cases count. How does Argus calculate this?
Case are not retrieved under PADER/ NDA Report as expected. The report criteria seem to be correct. Am I missing anything?
NDA Report Logic, according to Argus:
The NDA (PADER) report will always select the listedness for the case/event that was consistent with the last expedited report submitted to the FDA. This is the expected functionality of Oracle Argus Safety system for any version.
In the Example 1 above, since the serious case was not resubmitted after the change in listedness, the PADER displayed the data as the listedness of the last expedited submitted report i.e., Listed. If there were a non-serious case where the event was considered listed but was later changed to unlisted because of an error in MedDRA coding, that case would be pulled into the PADER as a non-serious, unlisted case/event. This is because the case was never submitted to the FDA or any other regulatory agency.
For the 14 non-serious cases with conflicting listedness designations for the same MedDRA term; that was nothing other than poor data entry. Going back into the cases and correcting “emesis” to be listed was the only action needed. After the second run of the PADER, all 14 non-serious cases with “emesis” were properly shown as “listed” per the approved product labeling.
Argus always displays the aggregate report cases in the configuration (serious, non-serious, listed, unlisted) as they were when the case was last submitted. Since the non-serious case had never been submitted, Argus pulls the data as it is in the database at the time of the data pull.
The PADER report counts the distinct cases when it counts the total cases, and it counts the total number of events when it counts the total number of events. In example 3, the total number of distinct cases are only 2 for all 5 events in the above example. That is the reason it is showing 2 under Total cases column.
In Argus, the PADER report tracks the serious cases that have the expedited submitted report within the DLP date range. In the case of non-serious cases, it will be pulled into PADER even without submitted reports. When you do not see a serious case in the report, verify the expedited report was submitted
Our team has seen an uptick in the number of questions and anxiety about “erroneous counts” of listedness and/or case number during DLP. To some degree, the panic is akin to toilet paper buying at the onset of COVID-19 in the US. Let us take away the mystery behind Argus logic so your next DLP will not create anxiety and panic or worse, hours spent trying to figure out why the data pulled into the report does not seem accurate.
There are 2 options to reflect the count accurately in the NDA report generated from Argus.
- Consider resubmitting a serious follow-up report to the same agency i.e., US FDA in this serious case example. Cross check your coding guidelines, is there anything to guide the case processor when listedness is changed in a case previously submitted?
This option is an Oracle backend database change*. Reach out to your IT team to implement this change.
- Identify the case revision when the listedness was modified.
- Update the case revision identified in cmn_reg_reports Oracle backend database table.
*remember that changes to Argus from the back end do not create an audit trail – so proceed with caution and document within your change management system.
For the non-serious cases, simple data clean-up of the incorrect listedness was all that was needed.
The NDA report should be executed after either of the options and data clean-up are applied to reflect the counts of event/cases under appropriate columns.
All said and done, there are some known bugs and issues of the NDA report that should be considered during the troubleshooting of the issues.
Aggregate Best Practices Learned by Baptism with Fire:
- Aggregate reports to regulatory agencies, even one as simple as a PADER always require some re-work. If you find that your PADERs, PBRERs, DSURs have conflicting data requiring data clean up, then it’s time to look back at your case processing conventions and update accordingly. Perficient can help identify the cause and remediation, so no one develops a gastric ulcer around DLP time.
- Treat all aggregate reports as mini-projects. Start 60-90 days ahead of the DLP and review the draft data to ensure there are no cleanup issues and that the data is displaying as expected. This eliminates stress.
- Consider a quick 15-min monthly meeting with all cross-functional teams having a role in the aggregate report to ensure that everyone is aware of what reports are due, when they are due, and roles and responsibilities. At that point critical pieces are not omitted, and resourcing can be planned in advance. Consider a quick checklist that serves as a project plan with dates due so there are no misunderstandings. Don’t forget to assign someone who is responsible for any regulatory feedback regarding the submitted report.
- If there are issues with the way the data is rendered from Argus safety, it’s most likely the Argus logic and no reason to panic. Having a consistent case processing and aggregate report generation process with clear roles and responsibilities eliminates stress and mistakes, especially if you are juggling multiple reports at the same time.
- Remember that FDA has a waiver for the MAH where the PBRER can be submitted in lieu of the PADER to minimize duplicate work. See here for how to consolidate if you haven’t already:
- Starting early avoids the last-minute submission crunch and allows all groups to have the necessary time for their sections. It gives the medical writer time to knit together and format the report appropriately.
- QA is best done by a fresh set of eyes and not in the middle of the night, thus the generous timelines.
For help with Aggregate Report Issues, either finding the right process for your team or data issues; please feel free to reach out to Perficient’s PV Team