Skip Headers

Oracle® Health Sciences Pharmacovigilance Operational Analytics User and Administrator Guide Release 1.0 E23554-01 |
Home | Book List | Contents | Index | Contact Us

Previous | Next
| PDF · Mobi · ePub

# 1 Getting Started with OPVA

This chapter contains the following topics:

- Overview

- Architecture

- Reporting

- Regulatory Compliance

## 1.1 Overview

Business Intelligence has become a very important analytical tool for the pharmaceutical and related industries as more business operations are run globally in today's electronically wired world. By using the Oracle Pharmacovigilance Operational Analytics (OPVA) software tool, pharmaceutical companies and contract research organizations (CRO) can keep tab on how efficiently case processing is performed, their overall safety compliance with regulatory authorities, and a day to day assessment of drug safety personnel required to maintain a smooth operation of the drug safety department.

Oracle Pharmacovigilance Operational Analytics (OPVA) is an analytical and transactional reporting application based on a predefined set of key performance indicators (KPIs), facts, and dimensions with support for predefined and custom reporting. OPVA also functions as a decision support system to monitor process bottlenecks and compliance deviations. With the use of this analytical tool, it will be possible for the drug safety management to generate out-of-the-box set of compliance metrics reports via Oracle Business Intelligence Enterprise Edition (OBIEE) that can be integrated with existing ARGUS Safety application. The interactive OBIEE dashboard will provide solutions to business questions and present data in charts, pivot tables, and reports. The results could be further enhanced through charting, result layout and drill-down features.

Pharmacovigilance Organizations require insights into the following key drug safety business process areas that impact the performance of drug safety operation within a case processing site/multiple case processing sites:

- Case Receipt Compliance: Adverse event reports must be received by the drug safety department within the time frame as defined by the business in its Standard Operating Procedure (SOP) from internal as well as external sources.

- Case Volume: In order to assess the balance of required drug safety personnel versus the number of cases received on a daily basis, the drug Safety management needs to view the overall volume of cases including but not limited to subsets of serious vs. non-serious, case type, product type, pregnancy and lactation exposure cases (with/without adverse events) etc.

- Case Processing Time: Drug Safety management continually needs to determine if the cases are processed in an efficient and timely manner and ideally without needing re-work, in order to meet the regulatory submission deadlines.

- Cases Processed by a User/User Group: Drug Safety management requires the ability to determine if the workload is balanced. The number of cases processed by each user enables management to review how the work is being accomplished and understand how many cases a person can handle.

- Workload Allocation for Open/Current Cases: Drug safety management needs the ability to view real-time open work, the associated status, its due date, and the amount of time it has been in a given status so workload can be proactively managed and continue to be balanced and re-balanced in the cases of personnel absence, vacations or over allocation.

- Compliance Maintenance: Drug safety departments need to process their expedited cases in a time-critical manner since the expedited reporting due date begins incrementing after the first employee or an agent of the company first learns about the adverse event associated with a company product.

- Pregnancy Case Tracking: Pregnancy case tracking includes counting pregnancy cases with and without adverse events. This information is typically needed for PSUR pregnancy section preparation and/or maintaining pregnancy registries.

- Root Cause Analysis: Regulatory submissions are late for a reason and a case may have a global and/or a local root cause for being late. The reason each submission is late needs be determined and tracked since the ability to categorize the root cause enables the company to take the necessary corrective and preventive measures.

### 1.1.1 What Can I Do Using Oracle Pharmacovigilance Operational Analytics?

OPVA integrates data from Oracle Argus Safety and additional sources, where appropriate, into a predefined data warehouse schema and generates both predefined and custom reports of key metrics across the pharmacovigilance spectrum. OPVA allows you to perform the following functions:

- Extract all necessary drug safety data from Oracle Argus Safety into a predefined data warehouse, for viewing through the rich dashboard and report interface of Oracle Business Intelligence Enterprise Edition Plus (OBIEE).

- Extract such data from other database sources as well, subject to the development of separate Extract Transform Load (ETL) programs for each database source.

- View predefined analytical reports delivered with the application.

- Rapidly create new reports using the extensive predefined cycle time, quality and volume based metrics across data management and drug safety operations processes.

## 1.2 Architecture

Figure 1-1 The Oracle Health Sciences Pharmacovigilance Operational Analytics Architecture

The OPVA architecture includes the following principal components:

- A predefined Intelligence application, based on Oracle Business Intelligence Enterprise Edition Plus (OBIEE), including Oracle BI Presentation Services, and a predefined set of Oracle BI reports, accessible through prebuilt interactive dashboards.

## 1.3 Reporting

OPVA provides reports for the two key drug safety functional areas - Retrospective Workflow Metrics and Current Metrics.

Retrospective Workflow Metrics Reports further include the following type of reports:

- Case Version Metrics Reports answer questions related to the volume of cases, and the time taken to complete a case, at case version level.

- Case Routing History Reports answer questions about how long it took to complete a workflow state (step) before transitioning to the next workflow state in a case. It will represent a log of all the workflow states an individual case safety report (ICSR) went through (routed to) in its workflow lifecycle.

- Case Workflow State History Reports answer questions about all the workflow states that a case has been through and the number of times each workflow state was repeated in that case.

Current Metrics Reports include the following type of reports:

- Pending Cases Report will answer questions related to pending on-time, due soon and overdue cases.

See Also:

- Chapter 2, "Using OPVA"

- Chapter 3, "Working with Reports"

- Appendix A, "Dashboards and Reports"

## 1.4 Regulatory Compliance

OPVA is designed as a single data-warehousing platform that facilitates integration of both non-regulated and regulated data. This single platform provides secure access to authorized users. It provides reduced total cost of ownership through reduced data integration costs and infrastructure maintenance costs, compared with multiple warehousing solutions.

The primary regulatory requirements include: (i) data tracking and (ii) Extract Transform Load (ETL) Version Management.

### 1.4.1 Tracking Data

The origin of any data displayed in a report must be traceable to its source, and all transformations applied to the data must be accessible. Data sourced from Oracle Argus Safety is traced by the following criteria and rules:

- Load: When the data was loaded from the source database into the staging tables.

- Staging Mapping: The version of ETL mapping used to transform the data from source to staging table, and when it was executed.

- Target Mapping: The version of ETL mapping used to transform the data from the staging table to target tables, and when it was executed.

- Transformations and calculations performed on the data within the OBIEE Repository can be versioned and saved permanently in a third-party versioning tool.

- Calculations can also be performed in reports managed through OBIEE Analytics. The OBIEE Analytics Administrator is responsible for controlling what calculations are performed, and who can perform them.

### 1.4.2 Managing ETL Versions

You can use a third-party versioning tool or in-built functionality of Informatica to manage ETL versions.

### 1.4.3 Executing the ETLs

Execution of the ETLs is controlled by Oracle Data warehouse Administration Console (DAC). You can create users and set the roles for various accessibility in DAC. Please refer to the DAC Administration and User Guides for more information.

### 1.4.4 Security

Data within the data warehouse is secure from updates by unauthorized personnel, and can only be updated through controlled execution of ETL mappings.

The ability to modify ETL routines is restricted to a user group or role of ETL developers. Access to execute ETL routines is restricted to a specific privilege, which can be granted to a user group or role.

In addition, access to data is available for authorized personnel only constrained through user groups or roles.

See Also:

Chapter 7, "Implementing Security"