Go to primary content
Oracle® Argus Analytics User's Guide
Release 8.1
E76207-01
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

1 Getting Started with Oracle Argus Analytics

This chapter contains the following topics:

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 Argus Analytics 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 Argus Analytics 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. Oracle Argus Analytics 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 Argus Analytics?

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

  • Extract all necessary drug safety data from Oracle Argus Safety into a predefined data mart, 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 Argus Analytics Architecture

Surrounding text describes Figure 1-1 .

The Oracle Argus Analytics 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

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

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

  • Case Version Metrics Report answers questions related to the volume of cases, and the time taken to complete a case, at case version level.

  • Case Routing History Report answers 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 Report answers 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.

  • Case Work History Report answers questions related to the details of the workflow states a case version went through in its workflow lifecycle. It can be used to derive the actual work time spent in each workflow state per user or the version or at the case level.

  • User Case Work History Report answers questions related to the total time a user spends in working on a case version, total actual work time spent in each workflow state, average time spent in working on one case version by one user in one workflow state.

  • Expedited Report History Report answers questions related to the timeliness and volume of single case report submissions, which includes expedited reports and reports sent to a business partner for submission, in relation to the regulatory due date.

  • Report Routing History Report answers questions related to the details of the workflow states an expedited report went through (routed to) in its workflow lifecycle.

Current Metrics Reports include the following types of reports:

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

  • Pending Report answers questions related to pending, due soon, and overdue single case report submissions, which includes expedited reports and reports sent to a business partner for submission, in relation to the regulatory due date.

See Also:

1.4 Regulatory Compliance

Oracle Argus Analytics 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/ODI to manage ETL versions.

1.4.3 Executing the ETLs

In case of Informatica, the execution of the ETLs is controlled by Oracle Data Warehouse Administration Console (DAC). You can create users and set the roles for various types of accessibility in DAC. Please refer to the DAC Administration and User Guides for more information.

In case of ODI, the execution of the ETLs is controlled by ODI Studio. You can create users and set the for various types of accessibility in ODI Studio. Please refer to the ODI documentation for more information.

1.4.4 Security

Data within the data mart 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"