4 Reporting Algorithms

This chapter contains the following topics:

Section 4.1, "Labeling Algorithm"
Section 4.2, "Choosing a Categorization Algorithm for Compiling PBRER and DSUR"
Section 4.3, "Initial or Follow-up Algorithm"

4.1 Labeling Algorithm

The system calculates listedness (the expectedness of the undesirable effect experienced in an AE) using an option that you choose when running the Periodic Benefit Risk Assessment Report (PBRER) or Development Safety Update Report (DSUR).

The following options are available:

Use Assessment in cases from Event Assess table
Use Assessment in cases from the Event Assess table for the configured License List
Use Event Assess table with Report type + datasheets
Re-assess cases against datasheet in effect at the beginning
Re-assess cases against datasheet in effect at the end

This lets you specify which datasheet to look against for Listedness when running the report.

When using the Event assessment from the case, the system considers only the As Determined listedness of the primary event or the case listedness.
When you select the ALL datasheets Report Type, the system uses the most conservative listedness for the primary event, or the Case Listedness.
When you select a specific datasheet, the system bases listedness on this datasheet.
The datasheet for listedness on the Inclusion Criteria is calculated for ALL products within the case and not only for the first suspect drug.

4.1.1 Listedness Determination based on Event Assess Table

When you choose an option that bases listedness on the data in the Event Assess table, listedness is determined as of the time when you run the report.

Use Assessment in cases: Listedness determination is based on the events processed in the Events tab > Event Assessment section of the case form. This means that the system uses the Case Assessment Table to drive the listedness for the periodic report.
Use Event Assess Data with License List: Listedness determination is based on the case event assess table corresponding to the configured license. It ignores others from the case. This option is not available for PBRER and is applicable to DSUR only.

4.1.2 Listedness Determination Based on Event Assess Table and Datasheets

Listedness determination is based on the case event assess table corresponding to the selected report type combined with the datasheet containing the inclusion criteria. The system ignores listedness data for the case in other datasheets.

4.1.3 Listedness Determination based on Datasheets

When you choose an option that bases listedness on datasheets, the date of a datasheet figures in its inclusion in the listedness determination.

Re-assess cases against datasheet in effect at beginning: Listedness determination is based on the earliest datasheet for the product of the PSUR, regardless of the current assessment in the case.

This option re-assesses all cases in the line listings based on the valid (frozen) datasheets on or before the selected start date of the reporting period.
- If no datasheet has an active date on or before the start date of the PSUR configuration, an error message appears and the report is not generated.
- The Report Type selection for All datasheets in the Inclusion Criteria overrides the Re-assess cases against datasheet in effect at beginning option. When you select All, the system bases listedness on the assessments in cases.
Re-assess cases against datasheet in effect at end: Listedness determination is based on the latest datasheet of the periodic report regardless of the current assessment in the case.

This option re-assesses all cases in the line listings based on the valid (frozen or active) datasheets on or before the selected end date of the reporting period.
- If no datasheet has an active date on or before the end date of the PSUR configuration, an error message appears and the report is not generated.
- The Report Type selection for All datasheets in the Inclusion Criteria overrides the Re-assess cases against datasheet in effect at end option. When you select All, the system bases listedness on the assessments in cases.

Note:

The system acts on the Re-assess cases against datasheet in effect at end or Re-assess cases against datasheet in effect at the beginning options only when a specific datasheet is selected. The system does not do a full assessment on all licenses for the product. For example, when you select the ALL datasheet option, the system derives the assessment from the cases even if Re-assess cases against datasheet in effect at end or Re-assess cases against datasheet in effect at the beginning are selected.

4.1.4 Additional Considerations for Determining Listedness

Note the following additional considerations that apply to the determination of listedness for events or cases.

For the re-assess option, the system does not re-assess case level listedness if the common profile configuration for Case Inclusion criteria for the ICH PSUR/CTPR report based on Listedness is set to Use case level listedness. However, the system does recalculate event level listedness based on a selected algorithm.
If the above configuration is set to Use listedness of the primary event, the system recalculates case level listedness based on the selected algorithm.
You must limit a listedness assessment to target products.
If no datasheet is selected in the inclusion criteria and the re-assess option is based on the datasheets, the system uses the datasheet of all the licenses for the selected product and recalculates the listedness based on the most conservative approach.
If multiple products are part of the PSUR or CTPR report configuration and these products are also available in a case, the system bases the listedness assessment on the most conservative approach for case level listedness. Consider the following example:
- Product A and Product B are target products.
- Both products are available in the case.
- The case has a primary event of Pyrexia and an event of Fever.
For Product A, Pyrexia is a listed event but for Product B, Pyrexia is an unlisted event. The case level listedness is marked as Unlisted.

For event level listedness, the same rules apply when assessing the case for multiple licenses of a product having different datasheets.
If listedness for a case or event is not listed, it is counted under unlisted. This represents the scenario where event assessment has not been done and is NULL or unknown.

4.2 Choosing a Categorization Algorithm for Compiling PBRER and DSUR

For custom aggregate reports, you can select either of the following case count categorization algorithms:

The PBRER case count categorization algorithm retrieves cases based on the target drug list.
The DSUR case count categorization algorithm retrieves cases based on the product type within the study configuration.

The Clinical Drug Role Algorithm report parameter, is available in the PBRER and DSUR template for setting the default algorithm used for OOB reports.

4.3 Initial or Follow-up Algorithm

Aggregate reports generated through the BI Publisher use a different initial or follow-up algorithm from the algorithm for Argus Native reports:

Use the Follow-up Algorithm parameter to select a method for categorizing cases as initial or follow-up in the aggregate reports.

The Follow-up Algorithm parameter has the following values:

Use Submission Tracking: Used as default algorithm for reports executed from Argus Safety UI. This option is selected by default when you run reports from BIP console or BIP scheduler.
User Initial Receipt Date

4.3.1 Using Submission Tracking

A case is categorized as follow-up if it previously was submitted to the same regulatory agency and report form; otherwise it is categorized as initial. The same logic applies to cases missed in the previous period, and those cases are marked as initial or follow-up based on the submission record:

Initial: No submission record exists for that case, agency, and report form combination.
Follow-up: The case has a periodic submission record for the current report form and agency.

4.3.2 Using Initial Receipt Date

A case that is part of the main case series is marked as Initial if the initial receipt date of the case falls in the current reporting period; otherwise it is categorized as follow-up. The same logic applies to cases missed in the previous period, and those cases are assessed for initial receipt date only.

The system uses the existing Argus logic to find cases missed in the previous period. However, to categorize those cases into initial or follow-up, one of two algorithms (Initial of Follow-up) is used.