5 Design Structure

5.1.1 BI Publisher Data Model

The BI Publisher data model comprises:

• The data set for each report

• Event triggers

• Parameters and associated lists

5.1.1.1 Data Sets

Each BIP report has its own data sets. A data set is the XML data file used to generate the report output. Figure 5-1 displays the data set of the Periodic Benefit Risk Assessment Report (PBRER).

Figure 5-1 Data Sets

Each box represents a query that can fill in a group.

5.1.1.3 Parameters

Parameters are part of the data model. Figure 5-2 displays the parameters of the PBRER.

Figure 5-2 PBRER Parameters

Description of "Figure 5-2 PBRER Parameters"

The data model has the following types of parameters:

• Text

• Menu (list of values)

• Date

Text parameters are the simplest form. If you provide a default value, the system considers it automatically when no value is passed.

Menu parameters are LOVs and are associated with attached queries. For example, the AGENCY parameter is associated with the query in Figure 5-3.

Figure 5-3 Menu Parameters

Description of "Figure 5-3 Menu Parameters"

Argus Safety does not use date type parameters.

Note: The default values take precedence even if there is a value present in the report configuration and you did not select a value during report execution.

You may see many -999999999 values as the default values. Inputting a value of -999999999 would show the -- SELECT -- record on the BIP Parameters screen. When no value is selected, the report tries to fetch any default value present in the report configuration.

For example, for Main Case Series, when the parameter value is not selected and is left at -- SELECT --, the report selects the main case associated with the report configuration.

Enterprise ID and Report Configuration Name are mandatory parameters. The report fails if either of these parameters is not submitted.

5.1.2 BI Publisher Report Layout

BI Publisher Periodic Reporting uses Rich Text Format (RTF) for its templates. The layout maps the data sets and displays data at run time. You can also design the data model so the template calls other layouts within itself.

Figure 5-4 displays a portion of the PBRER data model. The report template calls other templates from the Cover and Summary pages.

Figure 5-4 PBRER Data Model

Description of "Figure 5-4 PBRER Data Model"

5.2.1 Argus Safety UI Entry

To configure a report, navigate to the Periodic Report Configuration screen and enter the required configuration. The system saves this data in the required configuration tables.

You can either generate the case series or run the BIP report in a single step. A case series is generated in both cases.

For an ICH PSUR configuration, the following case series can be generated:

• Main Case Series

• Cumulative Case Series

• Section 6.2 Case Series

• Ad hoc Case series (1-4) when ad hoc listings are supplied

For a CTPR configuration, only Main Case Series and Cumulative Case Series tables are present.

The case series are stored in the case series tables.

5.2.2 BI Publisher Data Flow

If you run the report from the Argus Safety UI directly, the system passes only the Enterprise ID, Report Configuration, Print As, and Reg Report ID parameters. Other parameters are picked up if no default values are provided at the BIP level.

1. Navigate to the BIP report that displays the parameter page.

2. Select the mandatory parameter ENTERPRISE ID.

   This selection executes the associated LOV query.

   The selected value is verified by the query present in the CFG_RPT_AGG_PARMS table for the parameter.

   After verification, the enterprise ID is set for the session.

3. Select the mandatory parameter REPORT_CONFIGURATION.

   This parameter determines whether the report will be in the Data Lock Point (DLP).

   If the case series parameters are not selected, the default case series associated with this report configuration is set automatically.

   This parameter is an LOV and the query present in the CFG_RPT_AGG_PARMS table for the parameter validates the selected value.

4. Input the other parameters, and click Submit.

   This invokes the Before data trigger that calls the f_beforedata function of the pkg_agg_rpt package.

This function:

1. Sets up all parameter values from the BI Publisher to Package variables.

2. Validates whether the mandatory parameters have been supplied.

3. Checks if the user's access has expired.

4. Determines whether the BIP report call is made from the Argus Safety UI or from the BIP console.

5. Handles case, study, or site security.

6. Finds the BIP report job.

7. Inserts records in CMN_REG_REPORTS.

8. Inserts records in PER_RPT_QUEUE and PER_RPT_STATUS.

9. Obtains the default values of all parameters using CFG_RPT_AGG_PARAMS.

10. Determines whether the report is DLP.

11. Populates the data for listedness, drugs, events, event to drugs, and case data.

12. After the case data has been populated, fills in the health authority details and drug names.

13. Sets up the lexical parameters, if any.

14. Based on the persist data common switches, fills in the data for MART tables:

    1. PERSIST_BIP_DATA: whether data from GTT needs to be moved to RM tables.

    2. PERSIST_DURATION: number of days for which the data is to be left at RM tables.

This results in the package filling in the complete data for data sets.

1. After the PLSQL code is complete, the BI report internally generates the data XML, renders the pages, and stores the output in its repository data.

2. The database job calls the pkg_rpt_util.p_fetchrptoutput function, which obtains the list of reports that are run based on the RPT_AGG_BIP_JOB table.

3. The database then queries the BIP Metadata Repository (MDR) and verifies that the report is complete. If the report has failed, the database updates the failure status and proceeds to the next report.

4. If the report is successful, the database checks if the Draft/Final tables are updated.

5. The system copies the report output blob to the reporting tables. It updates CMN_REG_REPORTS and the corresponding records in the PER_RPT_QUEUE and PER_RPT_STATUS tables.

After this operation is complete, you can view the report output in BIP and Argus Safety.

5.3.1 User Exits

You can use user exits to customize reports. Every population algorithm contains a user exit at the end during database selection.

A user exit lets you:

• Update records

• Insert records

• Delete records

• Manipulate the already filled data for formatting

Table 5-1 contains the list of user exits.

5.3.2 BIP Custom Schema for Cloud

For Argus Safety on Cloud, you might not be allowed to make changes as in the BIP Owner schema. Therefore, you can execute a script that creates a new schema on which you can add your own views, synonyms, packages, functions, and so on.

The new schema is created in the Argus Safety database and grants access to the BIP Owner.

5.3.3 Adding or Modifying a View

You can create your own view in the custom schema. If these views directly access BIP schema objects, you might need to provide grants. After the BIP schema is created, it has access to this view and can be utilized in the package through user exits.

5.3.4 Adding a Column to the Existing Table

Temp tables provide custom columns for customer use. However, there might be instances when you want to add further tables. You can do this in the following ways:

• Adding the columns directly into the table and manipulating it.

• If you are not allowed to add directly, you can create a replica of the table in the custom schema along with the new columns needed.

The BIP schema is provided a grant for the new object and a synonym is created.

Then, the data can be inserted in the new table.