9i and 10g difference

Oracle® Adverse Event Reporting SystemAdministrator’s Guide

Release 4.5.2

B10330-03

September 2005

Oracle Adverse Event Reporting System Administrator’s Guide, Release 4.5.2

B10330-03

Copyright © 2003, 2005, Oracle. All rights reserved.

The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.

If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software—Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.

Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.

Contents

Preface ............................................................................................................................................................... xiii

Intended audience..................................................................................................................................... xiiiDocumentation Accessibility ................................................................................................................... xivNew in Oracle AERS 4.5.2 ....................................................................................................................... xivStructure ..................................................................................................................................................... xvRelated Documents .................................................................................................................................. xviiConventions ............................................................................................................................................. xviiiChecking MetaLink................................................................................................................................. xviii

1 Oracle AERS overview

Lock Manager............................................................................................................................................ 1-1Oracle AERS interface ............................................................................................................................. 1-1

Navigator panel.................................................................................................................................. 1-1Console ................................................................................................................................................ 1-1Message line........................................................................................................................................ 1-1Status line ............................................................................................................................................ 1-2Toolbars .............................................................................................................................................. 1-2

Oracle AERS features .............................................................................................................................. 1-2Basic querying (search) techniques ................................................................................................. 1-2Querying with wild cards ................................................................................................................. 1-2Function keys...................................................................................................................................... 1-3Shortcut keys (key commands) ........................................................................................................ 1-4Closing/exiting before saving your work...................................................................................... 1-4

2 Administration overview

Company product repository ................................................................................................................. 2-1Users and user group permissions ........................................................................................................ 2-1Workflow tasks/data entry...................................................................................................................... 2-2Data management..................................................................................................................................... 2-2Reports........................................................................................................................................................ 2-3Query .......................................................................................................................................................... 2-3Dictionaries ............................................................................................................................................... 2-3Controls ...................................................................................................................................................... 2-3

iii

3 Controls

Discussion of the Controls table ........................................................................................................... 3-1Listing and descriptions of AERS Controls ........................................................................................ 3-1

4 AERS Portal

Portal components.................................................................................................................................... 4-2Implementing AERS Portal .................................................................................................................... 4-3

AERS Portal Users and User Groups .............................................................................................. 4-3Modifying the AERS Home Page .................................................................................................... 4-3

Modifying the Home Page attributes....................................................................................... 4-3Modifying the Pharma Solutions section ................................................................................ 4-4The Administration section ....................................................................................................... 4-4Modifying AERS Folders ........................................................................................................... 4-4AERS Documents custom items ............................................................................................... 4-5AERS Reports .............................................................................................................................. 4-6

Modifying the AERS Portal Applications....................................................................................... 4-6AERS External Applications/Single Sign-on ...................................................................................... 4-6

AERS 4.5.2 ........................................................................................................................................... 4-6AERS 4.5.2 Global Maintenance....................................................................................................... 4-7AERS 4.5.2 Workflow Configuration .............................................................................................. 4-7

5 Managing company product information

Product Codes ........................................................................................................................................... 5-1Adding Product Codes...................................................................................................................... 5-1Updating Product Codes................................................................................................................... 5-2Deleting Product Codes .................................................................................................................... 5-3

Company Products ................................................................................................................................... 5-3Product details .................................................................................................................................... 5-3

Adding a Company Product ..................................................................................................... 5-3Updating Company Products ................................................................................................... 5-4Deleting Company Products ..................................................................................................... 5-5

Approvals ............................................................................................................................................ 5-5Adding an approval ................................................................................................................... 5-5Updating an approval ................................................................................................................ 5-6Deleting approvals...................................................................................................................... 5-6

Labeling ............................................................................................................................................... 5-7Adding Drug Labeling ............................................................................................................... 5-7Deleting drug labeling associated with company drugs ...................................................... 5-7

Lots ....................................................................................................................................................... 5-8Adding Lot details ...................................................................................................................... 5-8Updating Lot details ................................................................................................................... 5-9Deleting Lot details.................................................................................................................. 5-10

Exposure ........................................................................................................................................... 5-10Updating Exposure details ..................................................................................................... 5-10Updating Exposure details ..................................................................................................... 5-11Deleting Exposure details ....................................................................................................... 5-11

iv

Contacts ............................................................................................................................................ 5-12Updating contacts .................................................................................................................... 5-12Deleting a contact..................................................................................................................... 5-12

Packaging ......................................................................................................................................... 5-13Adding packaging details....................................................................................................... 5-13Deleting packaging details ..................................................................................................... 5-13

Product Labels........................................................................................................................................ 5-14Creating a New Label ..................................................................................................................... 5-14Creating a New Version of a Label............................................................................................... 5-15

Viewing Label Versions .......................................................................................................... 5-15Adding Event Terms ............................................................................................................... 5-15Label Qualifications................................................................................................................. 5-15

Activating a Label ........................................................................................................................... 5-16Copying an Existing Label............................................................................................................. 5-17

6 Maintaining the AERS-TMS Dictionary

Conceptual Overview .............................................................................................................................. 6-1AERS-TMS MedDRA Implementation ........................................................................................... 6-1AERS-TMS WHO Drug Implementation ....................................................................................... 6-1

Adding Company Products .................................................................................................................... 6-2Adding products to the AERS-TMS dictionary ............................................................................ 6-3Activating your newly added dictionary terms ............................................................................ 6-7

Using TMS Domains ............................................................................................................................... 6-7Creating and using TMS Search Objects............................................................................................. 6-8Running Batch Reclassify....................................................................................................................... 6-8

7 Studies

Maintaining Study Attributes ............................................................................................................... 7-1Study Security..................................................................................................................................... 7-2Study Products ................................................................................................................................... 7-2

Adding Studies ......................................................................................................................................... 7-2Updating Studies...................................................................................................................................... 7-2Deleting Studies ....................................................................................................................................... 7-2

8 Product Groups

Defining Product Groups ....................................................................................................................... 8-1Adding Product Groups .......................................................................................................................... 8-1Updating Product Groups....................................................................................................................... 8-2Deleting Product Groups ........................................................................................................................ 8-2

9 Configuring AERS for multilingual use

Overview of multilingual architecture ................................................................................................ 9-1Maintaining AERS Local Languages.................................................................................................... 9-1Setting a User’s Local Language ............................................................................................................ 9-2Maintaining Codelist Translations ....................................................................................................... 9-2

v

Maintaining Field and Window Label Translations ......................................................................... 9-3Adding Field Label Translations ..................................................................................................... 9-3Adding Window Label Translations............................................................................................... 9-4

Maintaining Error Messages and Translations................................................................................... 9-4Adding Error Message Translations ............................................................................................... 9-4

10 Supporting your work processes

Case statuses........................................................................................................................................... 10-1Action items............................................................................................................................................ 10-3Document templates ............................................................................................................................. 10-3

Creating the template PL/SQL .................................................................................................... 10-3Loading the template...................................................................................................................... 10-4Defining the template in the LETTERS table .............................................................................. 10-4

Workflow tasks ...................................................................................................................................... 10-5Defining Workflow tasks ............................................................................................................... 10-6Assigning Workflow tasks to users .............................................................................................. 10-8

Designing screens ................................................................................................................................. 10-8Global screens and fields configuration....................................................................................... 10-9

FIELD_ATTRIBUTES Table Description .............................................................................. 10-9WDW_ATTRIBUTES Table Description ............................................................................ 10-11

Modifying the global screens and fields configuration attributes ......................................... 10-12Revealing custom fields ............................................................................................................... 10-12Workflow-specific screens and fields configuration................................................................ 10-13

FIELD_MODES Table............................................................................................................ 10-13WINDOW_MODES Table .................................................................................................... 10-13

Modifying Workflow-specific screen and field configuration ............................................... 10-14Configuring the data entry Navigator panel.................................................................................. 10-14

Creating the Code List entry ....................................................................................................... 10-15Creating Record Groups .............................................................................................................. 10-15Creating the SQL statement to display the Navigator view................................................... 10-16

Configuration consistency constraints............................................................................................ 10-17

11 Managing Users And User Groups

Overview of Oracle AERS user security ........................................................................................... 11-1Security objects ................................................................................................................................ 11-1

User groups............................................................................................................................... 11-1Users .......................................................................................................................................... 11-2

Types of Oracle AERS security ..................................................................................................... 11-2Case ownership ........................................................................................................................ 11-2Case permissions...................................................................................................................... 11-2Oracle Roles .............................................................................................................................. 11-3Portal Roles/Groups ............................................................................................................... 11-3Oracle AERS User Roles.......................................................................................................... 11-3

Setting up Oracle AERS for users ...................................................................................................... 11-3Managing Oracle AERS Roles ............................................................................................................ 11-3Maintaining user groups...................................................................................................................... 11-4

Understanding user group permissions ...................................................................................... 11-5

vi

Adding permissions to a user group............................................................................................ 11-5Adding user groups........................................................................................................................ 11-5Updating user groups..................................................................................................................... 11-6Deleting user groups ...................................................................................................................... 11-6

Maintaining users ................................................................................................................................. 11-7Creating AERS users....................................................................................................................... 11-7Assigning Oracle passwords ......................................................................................................... 11-8Assigning roles ................................................................................................................................ 11-8

Baseline Oracle Roles............................................................................................................... 11-8Optional AERS Roles............................................................................................................... 11-9Other AERS Application Roles ............................................................................................ 11-10Portal Groups (Roles) ............................................................................................................ 11-11Assigning roles to a user ....................................................................................................... 11-11

Updating user attributes and permissions ................................................................................ 11-12User permissions.................................................................................................................... 11-13

Local privacy and security ................................................................................................................. 11-14Configuration Components ......................................................................................................... 11-14Example 1: Local Privacy configuration for patient name and address ............................... 11-15Example 2: Local Security configuration for assessment data ............................................... 11-15Configuration Procedure ............................................................................................................. 11-16

Record-level filtering.......................................................................................................................... 11-16Configuration components .......................................................................................................... 11-17Example 1: Reportability/Submission History filtering for local affiliate............................ 11-17Example 2: Investigation filtering for Product Complaint investigation users ................... 11-18Configuration Procedure ............................................................................................................. 11-18

Managing passwords .......................................................................................................................... 11-21Configuring passwords................................................................................................................ 11-21Unlocking Single Sign-On (SSO)................................................................................................. 11-21Configuring application-level timeout ...................................................................................... 11-22Resetting a user’s password ........................................................................................................ 11-22Changing the PORTAL30 Password .......................................................................................... 11-23

12 Data management

Change reason codes............................................................................................................................. 12-1TE_CASE_VERSION/TH_CASE_VERSION view .................................................................... 12-1

Duplicate checking ............................................................................................................................... 12-2Duplicate check API........................................................................................................................ 12-2

Description................................................................................................................................ 12-2Input parameters...................................................................................................................... 12-2Output ....................................................................................................................................... 12-3

Duplicate Check logic..................................................................................................................... 12-3Clinical AE Cases ..................................................................................................................... 12-4Non-Clinical AE Cases (Spontaneous, Registry, Literature, etc.) ..................................... 12-4Product Complaint Cases ....................................................................................................... 12-5

Copy Case ............................................................................................................................................... 12-5Generic implementation................................................................................................................. 12-5

Data derivation procedures ................................................................................................................. 12-8

vii

Case ID generation.......................................................................................................................... 12-8Updating the Case ID generation algorithm........................................................................ 12-9

Case data derivations ..................................................................................................................... 12-9Field/Record/Record block, DB derivations ...................................................................... 12-9Updating and compiling the derivation library .................................................................. 12-9Generating the library ........................................................................................................... 12-10Standard derivation procedures .......................................................................................... 12-11

Field code lists...................................................................................................................................... 12-13Adding new code lists .................................................................................................................. 12-14

Step 1: Create the new code list ........................................................................................... 12-14Step 2: Add individual code list items................................................................................ 12-14Step 3: Create a Record Group ............................................................................................. 12-15Step 4: Assigning code lists to fields ................................................................................... 12-15

Creating SQL lookup code lists................................................................................................... 12-16Updating existing code lists ........................................................................................................ 12-17

Updating an item in a code list ............................................................................................ 12-17Retiring code list values ........................................................................................................ 12-18Reactivating retired individual code list items.................................................................. 12-18

Deleting code lists ......................................................................................................................... 12-18Deleting individual code list items............................................................................................. 12-19

Edit checks ............................................................................................................................................ 12-19Updating the edit check program............................................................................................... 12-20Table descriptions ......................................................................................................................... 12-20

RULE_ATTRIBUTES table.................................................................................................... 12-21RULE_FIRING_MODES table.............................................................................................. 12-21

Edit check example 22Spell Check........................................................................................................................................... 12-22

Configuring for Microsoft Word................................................................................................. 12-23Installing JSpell in Oracle AERS ................................................................................................. 12-23

Reconciliation ...................................................................................................................................... 12-24Modifying Reconciliation............................................................................................................. 12-24Staging tables ................................................................................................................................. 12-26

RCN_CASES table ................................................................................................................. 12-26RCN_PATIENT table ............................................................................................................ 12-27RCN_PATIENT_VITALS table ............................................................................................ 12-27RCN_PT_AE_PROFILE table ............................................................................................... 12-28RCN_PT_CAUSE_DEATH table ......................................................................................... 12-29RCN_PT_DOSING table ....................................................................................................... 12-29

Clinical data extract file ..................................................................................................................... 12-30Coded field translations ............................................................................................................... 12-31Clinical extract load program...................................................................................................... 12-31

13 Configuring Case Browse

Overview ................................................................................................................................................. 13-1Modes................................................................................................................................................ 13-1Field Attributes................................................................................................................................ 13-1Relevant Field Modes ..................................................................................................................... 13-2

viii

Adding or Updating a Custom Browse Configuration .................................................................. 13-3Fields Available for Configuration .................................................................................................... 13-4Out-of-the-Box Case Browse Configuration .................................................................................... 13-6

14 Case Data Query

Query configuration ............................................................................................................................. 14-1Modifying existing query configuration...................................................................................... 14-1Adding new query fields ............................................................................................................... 14-4

Creating support views........................................................................................................... 14-4Adding the Query Table Join ................................................................................................. 14-5Adding a new field to the query screens.............................................................................. 14-5Adding an Exclude Flag to a new block ............................................................................... 14-6

Adding custom queries ........................................................................................................................ 14-6

15 E2B Configuration

Run-Time Parameters ........................................................................................................................... 15-1Export processing .................................................................................................................................. 15-2

Configuring E2B Export (submissions)........................................................................................ 15-2E2B_RECEVIERS Table .................................................................................................................. 15-2

Import processing.................................................................................................................................. 15-6Import Rules .................................................................................................................................... 15-7

E2B Data Mapping .............................................................................................................................. 15-11E2B Automation Features .................................................................................................................. 15-13

Supported Automation Features ................................................................................................ 15-13Gateway Event and MDN Processing........................................................................................ 15-14Batch_Import ................................................................................................................................. 15-15Error handling ............................................................................................................................... 15-16Configuring Automation ............................................................................................................. 15-17

16 Creating and managing document templates

Document templates ............................................................................................................................. 16-1Creating the template PL/SQL .................................................................................................... 16-1Loading the template...................................................................................................................... 16-2Defining the template in the LETTERS table .............................................................................. 16-2

17 Managing programs and reports

Installing new reports .......................................................................................................................... 17-1Registering new reports on the Oracle Report Security Server................................................ 17-1Installing new reports on Oracle AERS ....................................................................................... 17-2

Defining report parameters ................................................................................................................. 17-3Deleting reports ..................................................................................................................................... 17-4

Removing reports From the Portal Reports Security Registry ................................................. 17-4Deleting reports on Oracle AERS ................................................................................................. 17-4

Configuring Oracle AERS reports ..................................................................................................... 17-4Configuring code lists used by reports ............................................................................................. 17-5

ix

Managing report decode values.................................................................................................... 17-5Configuring default values for program parameters ..................................................................... 17-6Configuring report parameter cross-validation............................................................................... 17-6

Client extensions example 8Customizable views used by reports................................................................................................. 17-8

Configuring ad hoc reporting tools .............................................................................................. 17-9Adding the company logo for MedWatch report ............................................................................ 17-9

18 Submission management

Overview of Submission Tracking functions and supporting configuration ........................... 18-1Running the Submission Wizard .................................................................................................. 18-2

Maintaining Reportability Rules ....................................................................................................... 18-3Reportability Rule Syntax .............................................................................................................. 18-3Setting the case data level of reportability criteria ..................................................................... 18-4Creating or modifying a Reportability Rule Template.............................................................. 18-5Applying a Reportability Rule Template..................................................................................... 18-5Managing individual reportability for an Approval ................................................................. 18-6

Maintaining Agency Reports .............................................................................................................. 18-6Adding Agencies/Reports............................................................................................................. 18-7Updating and deleting Agencies and Reports............................................................................ 18-7AGENCY_REPORTS table definition .......................................................................................... 18-7

19 Oracle AERS dictionary architecture

Overview of AERS Dictionary Functionality .................................................................................. 19-1Dictionary Columns........................................................................................................................ 19-1AERS, Dictionary Management, and TMS .................................................................................. 19-2AERS Dictionary Related Functions............................................................................................. 19-2

AERS Dictionary API Definition ....................................................................................................... 19-2Dictionary Interface Data Model .................................................................................................. 19-3

Definitions................................................................................................................................. 19-3Dictionary Version Support and Domains .................................................................................. 19-3

SetDomain Function ................................................................................................................ 19-3GetCurrentDomainFunction Function.................................................................................. 19-4V_DICT_DOMAINS................................................................................................................ 19-4

Classification.................................................................................................................................... 19-4Batch Reclassify ........................................................................................................................ 19-6

Reporting and High Level Term Derivation............................................................................... 19-7V_ACTIVE_SUBSTANCES .................................................................................................... 19-8V_SPEC_CAT ........................................................................................................................... 19-8

AERS Dictionary Query ................................................................................................................. 19-8Dictionary Pipeline Function ................................................................................................. 19-9Dictionary Search Dialog Box .............................................................................................. 19-10

Derived Unexpectedness ............................................................................................................. 19-10Dictionary Content Views............................................................................................................ 19-11

V_MEDDRA_TERMS............................................................................................................ 19-11V_PRODUCT_NAMES ........................................................................................................ 19-11V_REGULATORY_GROUP_NAMES................................................................................. 19-12

x

AERS TMS Interface Module .......................................................................................................... 19-12AERS Standard Dictionaries in TMS.......................................................................................... 19-13

AERS enhancements to WHO Drug ................................................................................... 19-13AERS Enhancements to MedDRA....................................................................................... 19-15

Reporting view modes ................................................................................................................. 19-15Classic Mode........................................................................................................................... 19-15Clinical Compatibility Mode................................................................................................ 19-15

AERS/TMS Concept Mapping.................................................................................................... 19-15Interface Module Tables............................................................................................................... 19-16

AERS_TMS_DICTIONARY_COLUMNS Table ................................................................ 19-16AERS_TMS_TERM_ROWS................................................................................................... 19-17AERS Controls Table Entries................................................................................................ 19-17

Notes on AERS_Dictionary_API Package ................................................................................. 19-18GetCurrentDomainFunction ................................................................................................ 19-18GetLastOmissionKey............................................................................................................. 19-18ReclassifyCase ........................................................................................................................ 19-18Search....................................................................................................................................... 19-18

V View Implementation ............................................................................................................... 19-19Forms Implementation ................................................................................................................. 19-19Drill Down Views.......................................................................................................................... 19-19TMS integration Install................................................................................................................. 19-19

TMS Configuration and Dictionary Loading..................................................................... 19-20AERS Standard TMS API Install.......................................................................................... 19-20

Derived Unexpectedness and Product Labels .......................................................................... 19-20Metadata and Label Versions............................................................................................... 19-20Label Maintenance Form ...................................................................................................... 19-21

20 Architectural details

Audit trail................................................................................................................................................ 20-1Data model naming conventions ....................................................................................................... 20-1

A Oracle Clinical configuration

Setting up value lookups from Oracle Clinical................................................................................. A-1Step 1: Define record group............................................................................................................. A-1Step 2: Assign record groups to fields............................................................................................ A-2Step 3: Define the LOV columns ..................................................................................................... A-2

Specific Oracle lookups ......................................................................................................................... A-3Record group for clinical studies: OCL_STUDIES....................................................................... A-3

Record group definition............................................................................................................ A-3Field LOV Mappings ................................................................................................................. A-3

Record group for centers: OCL_SITES........................................................................................... A-4Record group definition............................................................................................................ A-4Field LOV mappings ................................................................................................................. A-4

Record group for Investigators: OCL_INVESTIGATORS .......................................................... A-5Record group definition............................................................................................................ A-6Field LOV Mappings ................................................................................................................. A-6

xi

Record group for patient details: OCL_PATIENTS (multicolumn) .......................................... A-7Record group definition............................................................................................................ A-8Field LOV Mappings ................................................................................................................. A-8

Oracle Clinical reconciliation views.................................................................................................... A-9

xii

xiii

Preface

The Oracle Adverse Event Reporting System® (AERS) allows you to capture, review, and report adverse events for a wide variety of product types that utilize worldwide investigational and post-marketing sources. This document, the Oracle Adverse Event Reporting System Administrator’s Guide, introduces and describes the major functions an Oracle AERS administrator must perform and provides instructions that enable an administrator to complete these tasks.

Oracle AERS 4.5.2 is only available in a Web Server architecture; this release does not support a client/server configuration.

Intended audienceThe intended audience for this manual includes the job classifications listed and described in the following subsections. It assumes that your organization has the expertise to perform the tasks associated with those roles. If your staff lacks these skills, we recommend that you engage Oracle Consulting.

Oracle database administratorsInstalling Oracle AERS requires a level of knowledge equivalent to having mastered the material in Oracle’s DBA Architecture and Administration course. You must be able to read SQL*Plus scripts and edit them. You must be able to run SQL scripts and review logs for Oracle errors. For ongoing administration, additional training as a DBA is essential.

System administratorsMaintaining an Oracle AERS network requires mastery of the following skills:

■ Microsoft Windows operating systems, in general

■ creating and managing user accounts and groups

■ installing Oracle software

■ managing settings through the Control Panel

■ managing network printers

■ creating services

■ UNIX:

■ creating and managing user accounts and groups

■ installing Oracle RDBMS software and patches

■ identifying space on a file system for Oracle database tablespaces

xiv

■ setting and using environment variables

Documentation AccessibilityOur goal is to make Oracle products, services, and supporting documentation accessible, with good usability, to the disabled community. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at

http://www.oracle.com/accessibility/

Accessibility of Code Examples in DocumentationScreen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.

Accessibility of Links to External Web Sites in DocumentationThis documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.

TTY Access to Oracle Support ServicesOracle provides dedicated Text Telephone (TTY) access to Oracle Support Services within the United States of America 24 hours a day, seven days a week. For TTY support, call 800.446.2398.

New in Oracle AERS 4.5.2 This section describes the major improvements to Oracle AERS 4.5.2 from Oracle AERS 4.5.1

Implement Derived UnexpectednessAERS is enhanced to support unexpectedness for each licence. Reports and the Submission Wizard can use the local unexpectedness against the core and local label. AERS derives the event to drug unexpectedness using data in the enhanced product repository for the core label and each drug approval. The user can override the derived value(s) in the case data.

Implement Local Receive DatesSome reporting jurisdictions impose special rules to determine when the clock starts. For example, in Europe the case must be medically confirmed. In Japan, the four elements: a patient, a drug, a reporter, and an adverse event, must be known to start the clock. A new data element is implemented to capture the local receive date and the agency or agency list to which a local receive date applies.

xv

Enhance the AERS Product Label RepositoryThe AERS product repository is enhanced to capture additional information about drug products and studies. The entity “Product Label” is implemented, which allows customers to define their product labels and associate each with the appropriate set of agencies and the appropriate MedDRA version.

A drug packaging table is implemented to capture the formulations and package sizes for a drug. A study attribute table is implemented to capture information about the study products and their role, such as study status, comparator products, treatment, Eudract number, blinding protocol, and blinded status.

Upgrade Oracle forms and Oracle reports to 10gThe AERS technology stack is upgraded to 10G from Forms 6 and Reports 9iDS.

StructureThis manual contains twenty chapters and one appendix:

Chapter 1, "Oracle AERS overview"This chapter introduces Oracle AERS, giving brief introductions about each Oracle AERS function and each part of the interface.

Chapter 2, "Administration overview"This chapter briefly describes the administration of different parts of the Oracle AERS system: these are the Company Product Repository, Case data routing, users and user group permissions, workflow and data entry, data management, reports, query, dictionaries, and controls.

Chapter 3, "Controls"This chapter provides an overview of all of the AERS’ system parameters called Controls and their default values.

Chapter 4, "AERS Portal"This chapter describes the Oracle AERS Portal implementation and how you can modify it.

Chapter 5, "Managing company product information"This chapter describes how to use the Oracle AERS repository of information about your products. Oracle AERS stores company product information in Product Codes and Company Products.

Chapter 6, "Maintaining the AERS-TMS Dictionary"This chapter provides a high-level overview of the AERS-TMS dictionary implementation and instructions on how to perform routine TMS maintenance activities required to use TMS with AERS and to take advantage of the AERS-TMS integration.

Chapter 7, "Studies"This chapter describes the creation, maintenance, and deletion of Studies, which you link to specific Product Codes to create security and distribution rules.

xvi

Chapter 8, "Product Groups"This chapter describes how to define and use Product Groups, which you can use to define combinations of Product Codes and Studies for routing and security permissions.

Chapter 9, "Configuring AERS for multilingual use"This chapter covers the multilingual features of Oracle AERS and provides directions for maintaining local language translations of codelists, field and window labels, and error messages.

Chapter 10, "Supporting your work processes"This chapter describes the use of work processes, which are tasks that must be performed on a case.

Chapter 11, "Managing Users And User Groups"This chapter describes how to define users and groups of users in an Oracle AERS database instance, and how to set their security privileges.

Chapter 12, "Data management"This chapter describes how to use each Oracle AERS function that manages adverse event data, including codelists, edit checks, duplicate checks, and reconciliation.

Chapter 13, "Configuring Case Browse"This chapter describes how you configure certain components of the Case Browse subsystem, including Code Lists, Data Entry Modes, Field Attributes, and Field Modes.

Chapter 14, "Case Data Query"This chapter describes the Case Data Query subsystem of Oracle AERS.

Chapter 15, "E2B Configuration"This chapter describes details on configuring the E2B import and export rules as well as configuring E2B Automation

Chapter 16, "Creating and managing document templates"This chapter describes how to create, load, and define document templates.

Chapter 17, "Managing programs and reports"This chapter describes how to define, modify, and manage Oracle AERS programs and reports.

Chapter 18, "Submission management"This chapter covers all aspects of configuring Oracle AERS submission management and tracking.

Chapter 19, "Oracle AERS dictionary architecture"This appendix provides more specific information about the architecture of Oracle AERS dictionaries.

xvii

Chapter 20, "Architectural details"This chapter explains relevant parts of the Oracle AERS architecture, including the audit trail and data model naming conventions.

Appendix A, "Oracle Clinical configuration"This appendix describes three types of integration you can perform in an combined Oracle AERS/Oracle Clinical configuration.

Related DocumentsThis section lists the manuals for all Oracle Pharmaceutical Applications products. You can order printed manuals from the Oracle iStore. From the iStore, search for the part number in parentheses.

Oracle Clinical DocumentationThe Oracle Clinical documentation set (A83790) includes:

■ Oracle Clinical Administrator’s Guide (A83791)

■ Oracle Clinical Getting Started (B12308)

■ Interfacing from Oracle Clinical (A83793)

■ Oracle Clinical Conducting a Study (A85201)

■ Oracle Clinical Creating a Study (A85200)

■ Oracle Clinical Installation Guide (A83779)

Oracle Clinical NLS Option Documentation The Oracle Clinical NLS Option documentation includes:

■ Oracle Clinical NLS Option User Guide (A90473)

Oracle Thesaurus Management System (TMS) Documentation The TMS documentation includes:

■ Oracle Thesaurus Management System User Guide (A82842)

■ Oracle Thesaurus Management System Installation Guide (A83780)

Oracle Adverse Event Reporting System (AERS) DocumentationThe Oracle AERS documentation set (B10328) includes:

■ Oracle Adverse Event Reporting System Administrator’s Guide (B10330)

■ Oracle Adverse Event Reporting System Installation Guide(B10331)

■ Oracle Adverse Event Reporting System Installation Guide (B10329)

■ Oracle Adverse Event Reporting System Quick Guide (B14419)

Oracle Clinical Remote Data Capture (RDC) DocumentationThe Oracle RDC documentation includes:

■ Oracle Clinical Remote Data Capture Classic Data Entry User’s Guide (B13921)

■ Oracle Clinical Remote Data Capture PDF Data Entry User’s Guide (B139201)

xviii

Oracle Clinical SiteMinder DocumentationThe Oracle Clinical SiteMinder documentation includes:

■ Oracle Clinical SiteMinder User Guide (B15643)

■ Oracle Clinical SiteMinder Installation Guide (B15645)

Oracle Clinical TrialMinder DocumentationThe Oracle Clinical TrialMinder documentation includes:

■ Oracle Clinical TrialMinder User Guide (B15644)

■ Oracle Clinical TrialMinder Installation Guide (B15646)

In addition, OPA publishes PDF-format Technical Reference Manuals (TRMs) containing proprietary information on internal tables and APIs. If you are a licensed customer, contact Oracle Support to obtain a free electronic copy. This is a list of the available TRMs:

■ Oracle Clinical Stable Interface TRM (A83796)

■ Oracle Thesaurus Management System TRM (A82841)

■ Oracle Adverse Event Reporting System Saved Queries TRM (B10353)

■ Oracle Adverse Event Reporting System Reports TRM (B10352)

■ Oracle Adverse Event Reporting System Edit Checks TRM (B10331)

ConventionsThe following text conventions are used in this document:

Checking MetaLink

The Oracle AERS product suite continues to grow and evolve. To help you use it and stay abreast of updates we provide between releases, it is a good practice to check MetaLink for information that enhances our released documentation.

To open the AERS product page on MetaLink, complete the following steps:

1. Open a Web browser to http://metalink.oracle.com.

2. Click the "Login to MetaLink" hyperlink and log in. The MetaLink portal opens, displaying general news from several categories. If you do not yet have an account, click "Register for MetaLink" and follow the instructions given on the registration page.

3. From the left column, click Top Tech Docs. MetaLink loads the Knowledge Browser Product Page.

Convention Meaning

boldface Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

xix

4. In the "Alphabetical List of Categories" drop-down field, scroll down and select the "Adverse Event Reporting System".

5. Click the Go button to the right of the drop down field. MetaLink loads the AERS Knowledge Browser Product Page.

xx

Oracle AERS overview 1-1

1Oracle AERS overview

Oracle AERS is a full-featured adverse event reporting system that enables you to capture, review, and report adverse events from clinical, spontaneous, and post-marketing sources.

Oracle AERS System Administrators have various responsibilities, which include managing security (from Oracle AERS sites to Product Groups to Users); generating regulatory and non-regulatory reports; gathering drug compound information; and administering code lists, studies, and reporter records.

Lock ManagerThe Oracle AERS Lock Manager prevents you from simultaneously editing a single case. As soon as a user begins to edit a case, the Lock Manager automatically locks it. If other users try to access the case being edited, the case is available to them, but on a read-only basis. The lock is automatically released after the edited case is closed.

Oracle AERS interfaceThis section briefly describes the Oracle AERS interface and main features. For a more complete description of Oracle AERS features and functions, see the Oracle Adverse Event Reporting System User’s Guide.

Navigator panelThe panel on the left side of each Oracle AERS screen contains a hierarchical list of the objects managed by the subsystem. The objects are displayed as folders that organize or categorize the information in the subsystem. For example, each of the Oracle AERS reports is displayed under the REPORTS folder. When you click an entry in the Navigator panel, detailed information about the item is displayed in the right-hand panel, which is called the Object Panel.

ConsoleThe thick, gray bar at the bottom of the screen is the console. Two lines, the Message Line and the Status Line, are available to display pertinent information.

Message lineTwo types of messages may be displayed on this line:

■ Oracle® Forms™ standard messages.

■ Application-specific messages

Oracle AERS features

1-2 Oracle Adverse Event Reporting System Administrator’s Guide

Oracle Forms includes built-in messages to cover standard operations. For example, if you try to run a query and no records are retrieved, Oracle Forms displays the following message: FRM-40301 Query caused no records to be retrieved. Re-enter.

Application-specific messages can include "hints" for completing procedures, help text, or error text. For example, at a maintenance screen, if you select File=>New Query, Oracle AERS displays the following message:

Enter a query; press F8 to execute, Ctrl+q to cancel

Status lineThe Status Line displays helpful information about particular fields or records in a block.

Toolbars Each subsystem contains its own toolbar, but the buttons are common to all subsystems. Depending on which subsystem you are using, each toolbar button represents an activity.

Oracle AERS featuresThis section provides a brief description of the main features of Oracle AERS. These include:

■ Basic querying (search) techniques

■ Querying with wild cards

■ Function keys

■ Shortcut keys (key commands)

■ Closing/exiting before saving your work

Basic querying (search) techniquesThe query method used in Oracle AERS maintenance modules is standard Oracle Forms query-by-example syntax. You can perform a query search in most fields in Oracle AERS. The wild card search is the query technique referenced in this Guide. If you need to perform more complex queries, see your Oracle Forms reference guide for specific syntax formats.

Querying with wild cardsWhen you enter text in fields to conduct a query search (including fields with alpha-numeric code tables), Oracle AERS retrieves only exact matches. You can

Table 1–1 Status Line symbols and their definitions

Symbol Definition

Record n/m Indicates the current record number (n) and the total number of records fetched for the block (m). The total number of records fetched in the black (m) may appear as a '?' until you have scrolled through the records

ENTER QUERY Denotes screen is in Enter Query mode, allowing you to specify selection criteria

List of Values Indicates a LOV dialog box for the current field is available


Oracle AERS overview 1-3

broaden your search criteria with the use of a wild card character so that small differences in spelling, capitalization, or punctuation do not prevent you from retrieving the records.

The wild card operators include:

For example, if you want to view all Product Codes with a first letter of "N", enter "N%" in the Product Code field on the Product Code Maintenance screen and press the F8 function key. Every Product Code starting with "N" displays.

To perform a wild card query search:

1. Press the F7 key to enter Query mode.

2. Place the cursor in the field you want to query.

3. Key in the character and the "%" wild card.

4. Press the F8 function key.

The query results display.

Function keysFunction keys are available on all screens. However, certain actions may not be available in every field. For example, if you select F9 (List of Values/LOV box) in a field with no LOV attached, no LOV box displays.

Operator Description Example

% Wild card (one or more characters) A%

_ Wild card (single character only) A_pirin

Table 1–2 Function keys

Key Action

F1 Show Help

Ctrl + F1 Show Function Keys

F3 Duplicate Field

F4 Duplicate Record

F5 List Members (Query only)

F6 Add Row

Shift + F6 Delete Row

F7 Enter Query

F8 Execute Query

Shift + F8 Print

F9 List of Values (LOV) box

F10 Save

Ctrl +E Zoom (Editor) box

Ctrl +Q Exit Oracle AERS; Exit Query Mode (Data Maintenance, List Management and Report subsystems)

Ctrl + U Clear item (field)



Shortcut keys (key commands)You may access screens and perform most actions by pressing the ALT key, then the underlined letter of the menu item and the desired action (e.g., ALT + M + C). For example, if you want to access the Administration screen in the Oracle AERS application, rather than selecting the Maintenance=>Administration menu option, you can depress the ALT key and press M, then A. The Administration screen displays. If you want to navigate through the code list listings, you can press ALT + A + N. This is the same as selecting the Actions=>Next menu option.

Closing/exiting before saving your workIf you attempt to close a screen or exit the application without saving your work, Oracle AERS prompts you to verify if you would like to save your changes. If you save your work before closing, you do not receive this prompt.

If you attempt to close a screen/exit the application without saving your work:

1. Do one of the following:

■ Select File=>Close.

■ Click the Windows close box to close the screen.

■ Click the Windows close box to exit Oracle AERS.

A Forms dialog box displays, prompting you to save your changes.

2. Click the Yes button.

A Forms dialog box displays the number of records applied and saved.

3. Click the OK button.

The system saves your work, then returns you to the Case Browse screen.

Ctrl + Z Undo last editing

Table 1–2 (Cont.) Function keys

Key Action

Administration overview 2-1

2Administration overview

Oracle AERS is flexible enough to accommodate different companies' safety reporting and pharmacovigilance processes. This flexibility is supported through a rich, meta-data driven configuration infrastructure. You must design and implement these configurable elements of the application in the context of your business processes, and you can adapt the system to accommodate regulatory or business process changes.

Company product repositoryThe heart of the configuration is the Company Product Repository. In this area of the system, you define the set of your products along with the full approval history, product labeling, lot and manufacturing history, drug exposure data for pharmacovigilance denominators, and regulatory contacts. A Company Product corresponds to the preferred drug or product name for your product.

You assign each product a Product Code for security controls and assistance in managing blinded clinical cases. When you enter a case into Oracle AERS, it receives a Product Code based upon the primary suspect product or clinical project, which in turn controls the ongoing access to the case.

Oracle AERS stores basic information about clinical trials as well. If you want to implement study-level security features (see "Users and user group permissions" on page 2-1) you must track the restricted studies in the Oracle AERS STUDIES table.

The system clusters Product Codes into Product Groups to assist in the management of security and routing. You assign Product Groups to Sites in later configuration steps to define case data routing rules, and to User Groups and Users to define product-based access permissions for case data.

Users and user group permissionsUsers and user groups form the foundation of the functional and case data security in Oracle AERS. A user is an individual who accesses the Oracle AERS system. Users correspond to an Oracle account in the local instances that they access. Oracle AERS User Roles control a user's access to functions (menu items and subsystems), Reports, which workflow tasks they perform, and other Oracle AERS-specific functions.

User groups are collections of users that share the same organizational structure (as opposed to job function). User groups are the basis of case ownership security if implemented, allowing you to restrict case read and update access to the user group that created the case.

You explicitly grant both users and user groups their Case Create, Case Read, Case Update, Case Delete, Assessment, and Submission permissions on a product basis. You

Workflow tasks/data entry


grant permissions by assigning product groups to the users and user groups. A user has permission to a case provided the case's Product Code is contained in at least one of the Product Groups that is assigned to that user, and to his user group. For example, a user has Case Update permission for a case as long as the case's Product Code is listed in one of the Product Groups assigned to the user and one of the Product Groups assigned to his user group.

In addition to the AERS User and User Group, each user has a corresponding Portal User which controls access to various Portal functions. The Portal User is also made a member of one or more Portal Groups, which can further augment or restrict a user’s access to Portal features.

Workflow tasks/data entryA Workflow Task consists of a set of screens and fields that are accessible to users when performing the task. You can control three primary attributes of the screen and field configuration within a Workflow Task: whether a field or tab stop is visible, whether a field is visible, and the tab sequence for each field. This control enables you to create a tailored set of screens that focus the user on the data that he or she must review or enter in the task.

Each Workflow Task in turn drives the case status transition depending on whether the user indicates that he has completed his task. When a user exits a case, he is prompted for the next case status for the case. The available cases statuses can be defined for each workflow task (and vice versa). You can also construct Tasks that have no impact on the case status.

There is also a set of configurable aspects of a field that are common to all workflow tasks. These include the field label, the codelist assigned to the field, and the field help.

Data managementOracle AERS includes a rich set of data management features to manage case consistency. These consistency rules include Edit Checks, which validate the internal consistency of the data (e.g. pregnant males), and reconciliation checks, which validate the consistency with your external clinical data management system.

Edit checks operate at the field level (validating consistency of a field against a codelist or external table), record level (validating consistency within a data record — e.g. start date versus stop date), and case level (validating fields across records — e.g. a dead person taking a drug). Case-level edit checks can fire on case save or case exit. You can configure each edit check to fire only during particular workflow tasks. The severity of the check can either be hard or soft: a soft edit check gives a warning but creates an on-line discrepancy if the user continues, while hard edit checks prevent the user from proceeding until the error is corrected. Because of their nature, you should only use hard edit checks when you can use a strong integrity constraint. You can add new edit checks, turn off existing edit checks, and modify the standard edit checks.

The Reconciliation module in Oracle AERS enables you to load or access external data. If you are loading data, you must configure the load control files to match your data input file, and map into the reconciliation staging area. If you are dynamically accessing data from your clinical data management system, you must replace the staging tables with views onto your clinical data. You may also tailor the reconciliation checks themselves.

Controls

Administration overview 2-3

ReportsOracle AERS reports are highly configurable. You can change the name of any report, the report category (which controls the folders that appear in the Report subsystem), the report security and priority.

The majority of the regulatory reports are supported by a suite of views that populate the report. Oracle AERS validates these views for the default configuration; your company must validate any changes to the views as part of your configuration.

Finally, you can configure the report parameters that drive the reports. Most commonly, you update the default values and whether a parameter is accessible to a user. Oracle AERS also includes parameter validation logic that you can tailor should your configuration require different constraints on the parameters.

To support regulatory compliance and tracking, Oracle AERS includes a table of Agency/Reports. You store an entry in this table for each country and report form that you submit to that country/agency. For example, for Germany, you may have the BfArM report for local cases, the CIOMS I, and the PSUR defined. You must define these reports for the automated submission tracking to function in Oracle AERS.

QueryThe Oracle AERS Query subsystem is fully configurable. Each query item is a generic field on a generic Forms block. The size and position of the fields is fully configurable. For each query item, the table and column that represents the data source is defined. The table and columns need not be constrained to Oracle AERS tables - you can add views and access external systems (assuming that there is an Oracle database link to the tables). The query join criteria for each table is defined along with the join condition (which can include outer joins). Sub-queries can be defined for a field as well as other special criteria for dictionary fields. Using this information, the SQL Generator constructs a validated SQL statement that is run against the data.

Some reports are driven from saved queries that are specifically created to support case selection. These include the periodic queries (NDA Periodic, PSUR) which are run independently from the report and metrics/process queries that are run along with the report (e.g. the Deleted Cases query for the Case Summary Report).

Queries also form the foundation for the Active Inbox. As part of the configuration, you define a set of Inbox queries, save them, then assign them to the user's Inbox.

DictionariesOracle AERS includes a rich interface to external dictionary structures for coding events, products, diseases and diagnoses. The interface supports auto-encoding of terms upon entry, flexible decoding of terms during reporting, and a powerful query interface that allows users to fully leverage the dictionary hierarchy when searching for cases. This is implemented using Oracle TMS, for more information, see Chapter 6, "Maintaining the AERS-TMS Dictionary".

ControlsThe Controls tables are present at each site. The tables contain a number of specific, site-wide parameters that control various features of the application.

Controls


Controls 3-1

3Controls

AERS uses system parameters termed Controls. The installation process creates or migrates the parameter names and values in the CONTROLS table. You maintain the CONTROLS table through the Site and Global Administration subsystems. This chapter provides an overview of all of the Controls and their default values. Other chapters in this guide provide specific details about relevant Controls where warranted.

Discussion of the Controls tableThe CONTROLS table has two columns: CONTROL_ID (the Control identifier) and CONTROL_VALUE (the actual value associated with the Control ID). In general, you alter the CONTROL_VALUE to reflect your specific AERS configuration requirements.

Listing and descriptions of AERS ControlsThe following table lists the Controls in Oracle AERS 4.5.2.

Table 3–1 AERS Controls Table

CONTROL_ID CONTROL_VALUE Default Value

#SPELL_CHECK_URL The URL to launch spell check. ../opa45/spellcheck.html

ACCESS FAT Values: Y/N. This control record is needed and set to Y only to enable accessing Field Attributes configuration tools from the AERS Data Entry screen.

Y

ADHOC_URL The URL to launch the browser-based ad hoc data visualization environment.

Discoverer Viewer on the Forms Server, plus Discoverer parameters to open the default document.

AERS_EXTAPP_ID The Portal object corresponding to the External Application Definition for Single-Sign On for the main AERS application.

103

AERS_FAT_EXTAPP_ID

The Portal object corresponding to the External Application Definition for Single-Sign On for the FAT module of the AERS application.

105

AERS_INSTANCE The AERS Instance.

Listing and descriptions of AERS Controls


AERS_LETTER_URL The URL used to launch the letter generation page. This item is not configurable.

Portal To AERS. Show Letter? p_lettername=LETTERNAME

AERS_MAINT_EXTAPP_ID

The Portal object corresponding to the External Application Definition for Single-Sign On support.

104

AERS_SCHEMA The AERS Schema name. AERS1

BROWSE_CASE_STS_RC

Reason code for updating case status records.

CST

BROWSE_SUBMIT_RC Reason code for updating submission records.

SBM

C2_APPA_RPT_FRM_LIST

CIOMS II Appendix A list of report forms that are treated as exceptions by the CIOMS II report. These are maintained as a codelist whose name matches the Control Value.

C2 AppA Rpt Frm List

CASEID_PREFIX Prefix used to generate Case IDs in Oracle AERS (minimally, it must contain a site-specific identifier to ensure the uniqueness of Case IDs across all Oracle AERS sites).

YYYYS1

CASE_CLOSED_STATUS

Case Status for a closed case. C

CLOSE_REASON_LIST CLOSE_REASON_LIST

DAYS_PASSWORD_VALID

Setting for the number of days user passwords are valid.

90

DECODE_DOSECHR Global setting as to whether the Dose fields should be decoded in reports.

N

DECODE_DRUGFORM Global setting as to whether the Drug Form fields should be decoded in reports.

N

DECODE_FREQUENCY

Global setting as to whether the Frequency fields should be decoded in reports.

N

DECODE_ROUTE Global setting as to whether the Route fields should be decoded in reports.

N

DEFAULT_LANG_CD The Default Language Code for installation.

en

DELETE_CASE_RC Reason code for deleting case records. DEL

DICT_LATEST_DOMAIN_ID

1

ENFORCE_PASSWORD_POLICY

Flag that turns off password expiration check. Customers who do not have external authentication may want to turn off AERS password policy and use only SSO policies.

N

ERROR_LOGGER_JOB The job ID for the AERS Error Logger. (Set at installation)

Table 3–1 (Cont.) AERS Controls Table



Controls 3-3

EXP_MW_RPT_FRM_LIST

List of MedWatch Report Forms that should be considered as Expedited by the NDA Periodic Report.

Exp MW Rpt Frm List

EXT_TERM_BROWSER The URL to launch an external dictionary browser. If you are using the internal browser, you should change the CONTROL_ID to #EXT_TERM_BROWSER.

http://www.pharma.oracle.com/pls/browser/tms_user_browser_finddemo.openframe?pdictid=72

FORCE_UPR_IN_QK_OPEN

Values: Y/N. When set to ‘Y,’ the Case ID entered in the Quick Open dialog box is automatically converted to upper case.

Y

GMT_TIME_OFFSET Difference in time (±)(HH:MM) between the local server time and Universal Time (e.g., an Oracle AERS site on the East Coast would have an offset value of +5:00). This value needs to be adjusted if the system is set for Daylight Savings time (e.g., +4:00 during Daylight Savings time).

0:00

HELP_URL_PREFIX The location of the xHelp system. http://forms_server/opa45/xhelp

INACTIVITY_TIMEOUT

The amount of inactivity time a user has before the application closes.

1200000

INTERACT_EVENT_TID

Dictionary preferred term ID for a drug interaction event (reports where list of drugs for a drug interaction are required)

10013712

LACK_EFF_PTID_LIST Preferred event term IDs equivalent to lack of effect (primarily used by CIOMS II)

LACK_EFF_PTID_LIST

MW_REG_NAME_LIST

Names used as MedWatch registry. MW_REG_NAME_LIST

PATIENT_CONTEXT_LIST

Custom codelist used to support Clinical Extract Load.

PATIENT_CONTEXT_LIST

PERIODIC_RPT_FRM Codelist corresponding to the list of Periodic Report Forms.

Periodic Rpt Frm

PORTAL_ADDITEM_URL

The URL called by Portal when AERS adds an item to the portal repository. This Control is not configurable.

wwv_additem.selectitemtype…

PORTAL_AERS_UG_ID The internal ID of the AERS_USERS Portal Group.

10

PORTAL_DOCUMENT_CAID

The internal ID of the Portal Document folder.

34

PORTAL_EDITITEM_URL

The URL called by Portal when AERS edits an item to the portal repository. This Control is not configurable.

wwv_edit_tab.edititem…

PORTAL_IF_PASSWORD

The Password for the Portal IF User. AERS_IF_USER

PORTAL_IF_USER_ID The User name for the Portal IF User. AERS_IF_USER





PORTAL_PLS_URL The URL for the Portal DAD. http://forms server/pls/portal30

PORTAL_REPORTS_CAID

The internal ID of the Portal Reports Folder.

33

PORTAL_SCHEMA The schema name where the portal repository resides.

PORTAL30

REFRESH_QTEMP_ACTION

Setting in Browse for determining if cases are unpicked or removed from a Case List after assessment is completed. (Note: These values are applicable only if Auto Refresh is checked in the User Security screen.) Values are:UNPICK -when user completes a case, the case is marked 'unpicked' in the Case List and the case status is updated from the Case Browse screen.DELETE – when user completes a case, the case is removed from the Case Browse screen.

DELETE

REPORT_SERVER The Reports Server service name. service name on the reports server

SITE_ID The Oracle AERS Site ID. S1

SPELL_CHECK_JSPELL_SERVER

This specifies the HTTP server and port where JSpell servlet is installed,. If left blank, it implies the JSpell servlet is installed in the same server as the Forms server.

e.g. jspell_server.oracle.com:80

SUB_EXCLD_STATUS_1

Setting specifying the case status of cases to be excluded from submission reports; e.g., exclude all cases with status of 1 (Login).

0

SUBWIZ_USE_EVENT_TO_DRUG_ASSESSMENT

When Y, the Submission Wizard uses the lowest level information available for determining reportability. When N, the case level flags are used.

Y

SW_E2B_ID_ORG_NAME

The company named used to generate long E2B ids

ORACLE

SW_E2B_ID_SOURCE Used as the source when adding an E2B case id to AE_OTH_CASE_REFS

Oracle AERS

SW_GEN_E2B_IDS When Y, the Submission Wizard creates the E2b report ids

Y

TERM_REASON_LIST Custom codelist used to support Clinical Extract Load.

TERM_REASON_LIST

TMS_INSTANCE The TMS Instance name. It is set automatically and is a required value in the API.

TMS_PROD_LEVEL_VT

Internal TMS ID numbers for various items.

151




Controls 3-5

TMS_XSYSTEM_KEY The external system integration key used by this instance of AERS to access TMS. Our standard is to use the AERS schema name.

AERS1

TOTAL_DAILY_DOSE Global setting as to whether the Total Daily Dose should be included in reports.

N

UNDELETE_CASE_RC Reason code for undeleting case records. UDL

US_REP_TYPE_LIST List of report forms used for FDA reporting. Used for counting follow-ups on MedWatch and periodic.

US_REP_TYPE_LIST

WARNING_TIMEOUT The inactivity time in seconds, before the timeout warning screen displays.

1200





AERS Portal 4-1

4AERS Portal

This chapter describes the Oracle AERS Portal implementation and how you can modify it. Refer to the Oracle Portal documentation for more comprehensive information. The documentation is available online at the Oracle Technology Network:

http://otn.oracle.com/docs/products/ias/doc_library/1022doc_otn/portals.102/p_tour/qt_home.htm

AERS makes extensive use of Oracle Portal features. The AERS Home page is a Portal page. The Portal Document Repository stores AERS objects such as Saved Queries and Lists, added documents and report output, and XML/SGML output from E2B. Portal manages the Single-Sign On features for launching AERS and can launch other applications.

Oracle Portal generates reports and charts with information about your users. For example, you can find out which pages and portlets are the most popular, who is adding the most content, what your users are performing searches against, and whether those searches return results. You can even determine their browser types and IP addresses. If the supplied reports and charts don't give you the information you need, you can build your own.

You can also access a set of monitoring tools that provide information about the database, including storage, sessions, and memory utilization. Database administrators can use this information to monitor the performance of the database, and to identify potential problems.

Portal architecture overviewOracle Portal has a three-tier architecture that scales to suit any sized company.

The tier components are:

Portal components


Application Server: Oracle 9iAS, including the Apache-based Oracle HTTP Server, which brokers transactions between Web clients, the AERS application, and the Oracle Server. OPA documentation refers to the combination of 9iAS and AERS as the front end.

Web client: the browser display logic on user computers.

Oracle Server: the back-end computer with the Oracle 8i database and the Portal installations.

Portal componentsAERS uses the following Portal components: Portal Pages, Applications, Content Areas, Report Server Security, and the External Applications. Oracle Portal supports secure customization, which allows individual users to personalize the contents based upon parameters established by Portal administrators.

Portal pageA Portal page is a basic browser page that can be personalized based upon settings established at the installation of AERS. A home page is divided into sections, each of which is represented as tab pages, and can contain portlets. AERS includes a basic homepage layout that you can modify for each installation.

PortletA portlet is a building block that supports features such as Favorites and portal applications. A portlet delivers content on a portal page. You can encapsulate and publish any Portal object as a portlet. Once published, if made available, you can add a portlet to a page, either as an administration activity, or as a personalization activity.

Content areasContent areas are composed of folders and items and are designed to securely manage information stored in the portal repository. Content areas can be designed to support custom items that have special, application-specific properties.

Implementing AERS Portal

AERS Portal 4-3

ApplicationsAn application is a collection of related components that insert, update, and publish data from a database. With Oracle Portal, you can build different types of components to publish data, including:

■ Forms display data in a form-like interface where you can add new information, or update or delete existing data.

■ Reports display data in a structured format.

■ Charts display data in a graphical format.

■ Calendars display data by date.

External ApplicationsOracle Portal provides Single Sign-on support through the definition of External Applications. You can create an unlimited number of External Applications and each portal user can then select one to display on their home page.

Implementing AERS PortalOracle AERS Release 4.5.2 includes a baseline portal environment. You can modify the AERS portal environment to suit your business practices. This section describes the objects in the baseline AERS portal environment, and the degree to which you can modify them.

AERS Portal Users and User GroupsEach Oracle AERS user account has a corresponding Portal user account with the same user name and password. You manage Oracle AERS and Portal accounts from within Oracle AERS. When you add a user from within Oracle AERS, Portal automatically creates the Portal user account. When users change their passwords within AERS, their Portal passwords also change.

There are several reserved users and groups within the AERS Portal implementation which are all created as part of the installation:

■ AERS_USERS

■ AERS_IF_USER

■ AERS_ADMINISTRATORS

■ AERS_DOCUMENT_MANAGERS

Modifying the AERS Home PageThe AERS Home Page is the main launch point for the AERS Application. It consists of two regions: A set of utilities on the left for logging in, launching applications, maintaining shortcuts to favorites, and other features, and a main section that has tabs to Pharma Solutions, Alerts, Case Metrics, AERS Folders, and Administration pages.

Modifying the Home Page attributesThe AERS Home Page is named AERS_HOME. To modify the default attributes of the AERS Home Page, log on and follow these instructions:

1. Connect to the AERS Portal and log on as the Portal Schema owner (PORTAL30).



2. Click the Edit Page hyperlink near the top right corner. A "Modify the Contents of the Page" window opens under the Portlets tab.

3. Click the Main tab. Enter AERS_HOME in the Name field, if necessary. You can make several other modifications to AERS_HOME in this tab.

4. Return to the Portlets tab.

5. Click the Edit button associated with the section you wish to modify.

The following topics provide instructions to modify each section.

Modifying the Pharma Solutions sectionPharma Solutions is an HTML portlet with a generic welcome message. The tab is granted to PUBLIC, which allows the tab to be displayed before a user logs onto the AERS Home Page. You can customize this section to add a corporate message. To customize the message:

1. Click the Edit Page link on the Pharma Solutions tab.

2. Click the Edit Defaults link.

3. Enter your customized HTML message.

4. Click OK.

5. Click Close.

You return to the AERS Home Page.

The Administration sectionThe Administration section includes several built-in Portal administration functions such as user and group maintenance. You can access many more administration functions from the default Portal page (HOMEPAGE).

Modifying AERS FoldersThe AERS Folders section displays the contents of the two AERS content areas for managing report output and folders/items: AERS Folders and AERS Reports. The Folders subtab contains the main folder and items in AERS. The view of the folders and items that appears here is identical to what the user sees in the AERS Case Browse subsystem. This region provides all the features available from within AERS, as well as a few additional features available only here, including moving items from one folder to another and setting folder/item security.

This region is visible to a user only after he or she logs into the portal and only to users who are members of the AERS_USERS group (by default, all AERS Users are added to this group).

AERS Folders is the main content area for the AERS repository. When users create folders, add documents, or save queries and lists, the items are stored in the portal repository and managed through this content area.

To add folders, alter folder permissions, or move items, you must edit the content area. To edit a content area:

1. Select the AERS Folders tab and the AERS Documents subtab.

The AERS Documents content area displays the folders and items in AERS Folders.

2. Click on the Edit link in the upper right corner of the content display area.


AERS Portal 4-5

Edit icons appear next to each object in the folder.

The baseline and validation installations of Oracle AERS 4.5 include a set of preconfigured folders:

Clinical Data. Contains the control files needed to load external clinical data into the reconciliation staging area. Access to this folder is limited to AERS_DOCUMENT_MANAGERS.

Saved Public Queries. A default location for standard saved queries. All AERS users have View permission on the subfolders and contents.

Saved Lists. A default location for saved lists. Like Saved Public Queries, all AERS users have View permission on the subfolders and contents. The folder contains a subfolder for each list type: Case Lists, Study Lists, Country Lists, Patient Lists and Product Lists.

Pharmacovigilance Queries. A default location of the pharmacovigilance/signal identification queries included with Oracle AERS 4.5. Access to this folder is limited to AERS_DOCUMENT_MANAGERS.

Reporting Queries. A default location of the queries designed to support periodic and other reporting functions included with Oracle AERS 4.5. Access to this folder is limited to AERS_DOCUMENT_MANAGERS.

SASPIRIN. A default location, included only in the Validation Install, to demonstrate the ability to create and manage product-specific content. The example includes three sub-folders: Product Literature, Surveillance, and Hepatotoxicity. Access to this folder is limited to AERS_DOCUMENT_MANAGERS.

E2B Output. A default location for storing E2B Output. In the validation install, the output directory for the E2B report is directed to this portal folder.

E2B Imports. A default location for storing E2B files for import. Users are free to upload files into any folder, but this folder provides a convenient place to manage these files.

User Folders. A standard location for users to create private folders and objects. Unlike the other folders in the content area, the Users Folder is managed by AERS_USERS, so any user may create folders and items. Folders and items created in the User Folders are only visible to the user that created them.

AERS Documents custom itemsWithin the AERS Documents Folder, there are seven custom item types corresponding to specific AERS objects. These custom item types enable special functions (like "run query" to be executed within AERS based upon the item that a user selects in Case Browse).

AERS E2B Output. Corresponds to E2B Output.

AERS Query. Corresponds to an AERS Saved Query. This item type has the portal property to display SQL from within the content areas.

Case List. Corresponds to an AERS Saved Case List. This item type has the portal property to display the cases within the case list from within the content areas.

AERS External Applications/Single Sign-on


Country List. Corresponds to an AERS Saved Country List. This item type has the portal property to display the cases within the country list from within the content areas.

Drug List. Corresponds to an AERS Saved Drug List. This item type has the portal property to display the cases within the drug list from within the content areas.

Patient List. Corresponds to an AERS Saved Patient List. This item type has the portal property to display the cases within the patient list from within the content areas.

Study List. Corresponds to an AERS Saved Study List. This item type has the portal property to display the cases within the study list from within the content areas.

AERS ReportsThe AERS Reports content area manages report output. Users can access reports that they have run from the Portal repository. Typically, no customization is required in this area.

Modifying the AERS Portal ApplicationsOracle AERS 4.5.2 ships with a simple example application called AERS_METRICS. The AERS_METRICS application contains three simple charts that present case volume by different case attributes: Cases by Product, Cases by Country, and Cases by Status. This tool provides an easy way to visualize and assess case data based on these three categories.

You can augment or modify these applications, or create new ones and publish them as portlets that users can add to their home pages as you permit.

1. Click the Case Metrics tab.

2. Click the Customize link.

The Customize Parameters portal page displays.

3. Enter a Title in the Display Name field.

4. Enter Query Options, Row Order Options, and General Options from the drop-down menus.

5. Click OK.

You return to the Case Metrics tab.

AERS External Applications/Single Sign-onOracle AERS 4.5.2 adds three External Applications to the Portal environment, one for each of the two main application components. You may choose to add additional External Applications to accommodate local language use of AERS, see Chapter 9, "Configuring AERS for multilingual use" for more information.

AERS 4.5.2The AERS 4.5.2 external application corresponds to the main AERS system (case management, query, reporting, etc.).


AERS Portal 4-7

AERS 4.5.2 Global MaintenanceThe AERS 4.5.2 Global Maintenance application corresponds to the AERS Global Maintenance subsystem, where administrators manage global configuration settings such as codelists, product details, E2B import and export rules.

AERS 4.5.2 Workflow ConfigurationThe AERS 4.5.2 Workflow Configuration application corresponds to the AERS Fields Attributes Table (FAT), where administrators manage configuration settings such as screens and fields, edit checks, data entry modes, and case statuses. You can access this tool two ways:

1. From the Portal Homepage by selecting the AERS 4.5.2 Workflow Configuration link from the External Applications area.

2. From within the AERS 4.5.2 application, by selecting Help=>FAT Configuration.



Managing company product information 5-1

5Managing company product information

Oracle AERS maintains a comprehensive repository of key information about your products. This information is an integral part of a large number of automation, security, and reporting features. By establishing a robust product dictionary, you can fully leverage Oracle AERS features and functions.

This section includes the following subsections:

■ Product Codes

■ Company Products

■ Product Labels

Product CodesA Product Code is a unique identifier for a collection of drug names and forms that share the same distribution, security, and export requirements. The Product Code enables you to quickly identify cases that have a common product identity and serves as the basis for product-based data access controls.

Each case receives one and only one Product Code. The case Product Code is derived during the case data entry process either from the primary Suspect Product, or from the Project. Specifically, the Product Code is derived from the Suspect Product for non-clinical cases and from the Project for clinical cases. Clinical cases are derived differently to support the initial capture of clinical cases as Blinded Therapy.

The derivation process relies heavily on the drug/product dictionary as well as the Company Products table (see "Adding Product Codes" on page 5-1).

Adding Product CodesA Product Code can be completely arbitrary, but Oracle recommends that you configure Oracle AERS such that a Product Code corresponds to a single chemical entity or product line and that the Product Code is the "common" name for the product. This approach affords two substantial benefits:

1. It provides a simple mechanism for managing access control

2. It allows a quick mechanism to identify clinical cases, prior to unblinding.

Note: You can maintain Product Codes by using the Oracle AERS Global Maintenance subsystem.

Product Codes


To add a Product Code:1. Select the Products tab from the Oracle AERS Global Maintenance subsystem.

The Products Maintenance screen displays with the list of Company Products visible in the Navigator panel.

2. Click the Add Record button if a Product Code is displayed in the Object panel, or simply place the cursor in the empty Product Code field.

3. Select the Product Codes tab.

The Product Codes screen displays.

4. Key in all fields:

■ Product Code – the name of the Product Code. Pick a name that is commonly used by your company to describe the product.

■ Description

■ Product Name – the name of the products that share this Product Code. You may assign the products here, or optionally, assign the Product Code when creating the product (see "Company Products" on page 5-3). If the product you enter does not already exist, Oracle AERS automatically creates it.

■ Form – Oracle AERS enables you to derive Product Code based upon the combination of Product Name and Formulation. Use this field if you have separate data access controls based upon formulation, or if you are maintaining separate entries in the Company Products table for each formulation (see "Company Products" on page 5-3).

5. Click the Save button or press the F10 key to save changes.

The new Product Code and any newly entered Company Products are saved to the database.

Updating Product CodesYou cannot modify Product Codes, though you can update the description of a Product Code. If you need to change the Product Code, you must delete it and then recreate it.

To update a Product Code description:1. Select the Products tab from the Oracle AERS Global Maintenance subsystem.


2. Select the Product Code you want to update by clicking once on the Product Code in the Navigator panel.

3. Key in changes to the Description field.


Oracle AERS saves the updated Description to the database.

Company Products


Deleting Product Codes

To delete a Product Code:1. Select the Products tab from the Oracle AERS Global Maintenance subsystem.

The Products screen displays with the list of Company Products visible in the Navigator panel.

2. Select the Product Code you want to update by clicking once on the Product Code in the Navigator panel.

3. Click the Delete Record button or select Edit=>Delete Record.

The Product Code disappears from the screen.


You do not receive a prompt. Oracle AERS deletes the Product Code from the database.

Company ProductsOracle AERS includes a repository of product information for each of the products for which you have marketing authorization (i.e. global regulatory reporting responsibility). Oracle AERS stores manufacturing details for each product, along with detailed regulatory contacts, labeling details, lot tracking, and the full approval history. Oracle AERS uses these details throughout the system to automate and track key regulatory and safety surveillance processes.

Product detailsThe key element in the Company Products repository is the product itself. Each company should maintain the complete list of all products for which they report adverse events. When establishing a Company Product, it is critical that the name given to the product corresponds to the Regulatory Group Name from your product (or drug) dictionary. For new products that have not yet appeared in commercial dictionaries, you must first add the product to your dictionary before proceeding with the rest of the configuration.

Adding a Company ProductIn the Oracle AERS dictionary implementation, we created a special dictionary level called the Regulatory Group Name (see Chapter 6, "Maintaining the AERS-TMS Dictionary" for more information). Your company product must map to one, and only

Caution: Deleting a Product Code removes the Product Code from all Product Groups that contain it and all Oracle AERS sites that receive cases associated with that Product Code. This deletion may impact future routing and may result in cases for that Product Code being removed from the Oracle AERS site. Before you can delete a Product Code, you must first remove all related child references from the drug detail screens.

Note: The Oracle AERS dictionary structure and interface are fully described in Chapter 19, "Oracle AERS dictionary architecture" of this guide.

Company Products


one, Regulatory Group Name. Once you have established the Regulatory Group Name for the product, you must then add it to the Company Product repository in the Global Oracle AERS Maintenance application.

1. Select the Products tab from the Oracle AERS Global Maintenance subsystem.


2. The Object panel should be blank; if it is not, then press the Add Row button or select Edit=>Add Record to get an empty screen for your new product.

3. Key in all fields.

■ Product Name – The Regulatory Group Name (from the dictionary) for the product.

■ Form – The Product Formulation (optional: only use if you are (a) storing separate details for the formulations such as approvals or product labels, or, (b) if you envision separate security or data access for particular formulations.

■ Product Code – The Product Code associated with the product. Oracle recommends that the Product Code is the same as the Product Name, but you are free to use any code.

■ Address – A two-line free text for company name and street address and city, state/region, ZIP/Postal Code

■ Reporting Name – The preferred or approved drug name for that agency or country.

4. Click the Save button, press the F10 key, or select File=>Save to save changes.

The new Product is saved to the database.

Updating Company ProductsTo update a product:



2. Select a Product from the Navigator panel.

3. Key in the appropriate changes.


Oracle AERS saves the changes.

Note: We recommend creating the Product Code first. See Adding Product Codeson on page 5-1.

Company Products


Deleting Company ProductsTo delete a product:




3. Place the cursor on any of the fields in the Object panel and press the Delete Record button or select Edit=>Delete Record.

You do not receive a prompt. The Product Code is deleted from the database.


ApprovalsOracle AERS stores the entire approval history for each product, for each country where the product is licensed for investigation or sale. The approval history for the product is useful information to track in Oracle AERS, and is the basis for determining the world-wide reportability for a case using the Submission Wizard. Maintaining an accurate approval history greatly assists your efforts to automate the regulatory submission and tracking process.

Approval information includes the country of registration, license, type, license number, and license date. The entity granting the license can be either a true country or a regulatory agency. You can utilize any entity that you need to track your submissions to, even partners or customers (if your company provides contract adverse event report services).

Local Unexpectedness is derived at the license level and is displayed on the Local Unexpectedness screen. You can assign a label and label version to each approval using the Approvals tab of the Products screen in Global Maintenance.

In anticipation of international implementation of ICH E2C Periodic Safety Update Reporting, you should create an Approval corresponding to the International Birth Date for each drug.

Each Approval also has the option of storing specific sender and receiver details that are used by E2B, for more information, see "E2B Configuration".

Adding an approvalTo add a product approval:



Caution: Deleting a Product invalidates the Product Code derivation for the cases involving that Product. This could have unexpected data access consequences. Oracle strongly recommends that you do not delete a product that appears in the case data. If you want to restrict the creation of new cases for that product, create a Product Group containing that product and assign the group to all User Groups with the Create permission disabled (see Case Data Permissions).

Company Products



3. Select the Approvals tab.

The Approval tab displays.


■ Country: The Country or Agency providing the license/approval.

■ Type: The license type

■ License Number

■ License Date

■ Reporting Name: The preferred or approved drug name for that agency or country.

■ Auto Label Flag: When you run Drug Labeling, if the flag is selected for an agency, then the derived value is copied into the override field on the Local Unexpectedness screen in the case data.

■ Label Name: After the product labels are created, you can associate the agency/approval with a drug label, by selecting a label from the codelist.

■ Label Version: The version of the label you wish to associate the approval with.

■ Label Type: The type of label. Choose from a codelist.


Oracle AERS saves the Approval to the database.

Updating an approvalTo update an approval:








Oracle AERS saves the changes to the database.

Deleting approvalsTo delete a Approval:






Company Products


4. Highlight the Approval record to be removed and press the Delete Record button or select Edit=>Delete Record.




LabelingCore unexpectedness is derived at the event to drug level, and is displayed on the Event-to-Product Assessment screen.You associate the core label name and brochure label name to a label you created in Label Maintenance (see "Creating a New Label" using the Labeling tab of the Products screen in Global Maintenance.

Adding Drug LabelingTo add Drug Labeling:




3. Select the Labeling tab.

The Labeling tab displays.


■ Core Label Name - Use the codelist to associate the core label with a product label.

■ Core Auto Label - When Drug Labeling is run, if this flag is selected then the value in the Unlistedness derived field is copied into the override field.

■ Core Label Version ID - Enter the Label Version ID.

■ Brochure Label Name - Use the codelist to select the Brochure Label Name.

■ Brochure Auto Label - When Drug Labeling is run, if this flag is selected then the value in the Core Brochure derived field is copied into the override field.

■ Brochure Label Version ID - Enter the Brochure Label Version ID.

5. Press the Save button or F10 to save changes.


Deleting drug labeling associated with company drugsTo delete a Labeling:


The Products Maintenance screen displays with the list of Company Products visible in the Navigator.


3. Select the Labeling tab.


Company Products


4. Highlight the Labeling record to be removed and press the Delete Record button or select Edit=>Delete Record.



Oracle AERS deletes the Labeling from the database.

LotsOracle AERS includes a flexible and extensive repository for storing lot information. The Lot tables and their associated data entry screens are designed for use by companies that do not have, or chose not to implement, direct access to their manufacturing system. Oracle AERS uses the Lot details in two primary ways: (a) to support data capture through a product-based list of values for lot details, and, (b) to support ad hoc query and reporting for potentially lot-related safety concerns.

Adding Lot details

To load Lot details directly into tables:

1. Prepare a text file that matches the following load specifications:

Note: If you have direct access to Lot details in an Oracle-based manufacturing system, you can replace the LOTS table with a view onto the manufacturing system and skip this section.

Column Req? Type Start Stop Description

DRUG_NAME Y varchar2(100) 1 100 The Product Name

DRUG_FORM Y varchar2(10) 101 110 Formulation. Use a “space” if no formulation is desired

LOT_SEQ_NBR Y Number(10) 111 120 A sequential number within Drug Name/Form

LABEL_LOT_NUMBER

varchar2(200) 121 320 The lot number printed on the product

FILL_LOT_NUMBER

varchar2(200) 321 520 The Fill Lot. Can be used flexibly to support lot tracking requirements.

BULK_LOT_NUMBER

varchar2(200) 521 720 The Bulk Manufacturing Lot. Can be used flexibly to support lot tracking requirements.

PACKAGE_LOT_ NUMBER

varchar2(200) 721 920 The lot number printed on the package (useful for combination packages with multiple components)

EXPIRATION_DT varchar2(8) 921 928 The expiration date for the labeled lot.

DISTRIBUTION_DT

varchar2(8) 929 936 The distribution date for the labeled lot.

Company Products


2. Copy the LOAD_LOTS.CTL file from the Oracle AERS installation CD.

3. Edit the file to reflect the filename for the lot data.


4. Run the LOAD_LOTS.CTL SQL*Loader file connected as the schema owner of Global Maintenance tables.

To add Lot details manually:




3. Select the Lot tab.

The Lot tab displays.


■ Label Lot

■ Fill Lot

■ Bulk Lot

■ Package Lot

■ Expiration Date

■ Distribution Date

■ Number of Doses

■ NDC

■ Manufacturer


Oracle AERS saves the Lot information to the database.

Updating Lot detailsTo update Lot details:



NUMBER_OF_DOSES

number(38) 937 974 The number of doses included in the labeled lot. Note: This field can be used flexibly to represent manufacturing volume.

NDC varchar2(100) 975 1074 The NDC number or product tracking number.

MANUFACTURER varchar2(100) 1075 1174 The manufacturing site for the Label Lot.

Column Req? Type Start Stop Description

Company Products








Deleting Lot detailsTo delete Lot details:






4. Highlight the Lot record to be removed and press the Delete Record button or select Edit=>Delete Record.

You do not receive a prompt. The Lot is deleted from the database.



ExposureOracle AERS stores product exposure data for use in calculating the denominator values for the pharmacovigilance reports. There is no predefined exposure measure imposed by Oracle AERS. Rather, the structure is a simple measure by time-period for a product, and optionally the form and indication.

Updating Exposure detailsYou may use SQL*Loader to load Exposure data into the DRUG_EXPOSURE table. or you may manually add exposure details in the Exposure tab of the Company Products Global Maintenance subsystem.

Column Data Type Req? Description

DRUG_NAME VARCHAR2(500) Y The Product Name. This must match a product in the Company Drugs table.

DRUG_FORM VARCHAR2(50) Y The Product Formulation. This field must match the Drug Form

for the Product in the Company Drugs table. This field is NOT NULL so if you have no Form, insert a space (‘ “).

EXPOSURE_MONTH

VARCHAR2(6) Y Month of Exposure. Format: YYYYMM

Company Products


To add Exposure details manually:




3. Select the Exposure tab.

The Exposure tab displays.


■ Exposure Month

■ Exposure Measure

■ Indication


Oracle AERS saves the Lot information to the database.

Updating Exposure detailsTo update Exposure details:









Deleting Exposure detailsTo delete Exposure details:


EXPOSURE_MEASURE

NUMBER The Exposure Measure. This must be consistent WITHIN a product, but can vary across product lines. For example, you may use manufactured quantity for devices, a prescription data for drugs. This information is used in determining denominator data for the pharmacovigilance reports and other support infrastructure (e.g. SafetyView).

INDICATION VARCHAR2(500) The indication for the product. Currently not used in any default Oracle AERS functionality, but available should you develop custom reports or features that manage exposure data at the indication level.

Column Data Type Req? Description

Company Products






4. Highlight the Exposure record to be removed and press the Delete Record button or select Edit=>Delete Record.

You do not receive a prompt. The Exposure detail record is deleted from the database.



ContactsA contact is the company employee whose name appears on an expedited report as the regulatory contact. A product can have one contact for each regulatory agency or country. Oracle AERS lists contacts by country.

To add a Contact:


2. Select the Contact tab.

The Contact tab displays.



Oracle AERS saves the Contact to the database.

Updating contactsTo update contact information:







5. Press the Save button or F10 or select File=>Save to save changes.


Deleting a contactTo delete a Contact:



Company Products





4. Highlight the Contact record to be removed and press the Delete Record button or select Edit=>Delete Record.




PackagingOracle AERS stores product packaging details including formulations and package sizes for a drug. You add packaging details in the Packaging tab of the Global Maintenance subsystem.

Adding packaging detailsTo add Packaging details:




3. Select the Packaging tab.

The Packaging tab displays.

4. Enter the packaging details.

5. Click the Save button.


Deleting packaging detailsTo delete packaging details:



Column Data Type Description

DRUG_FORM VARCHAR2(50) The product formulation.

PACKAGE_SIZE

NUMBER The size of the package.

PACKAGE_SIZE_UNIT

VARCHAR2(50) The units associated with the size of the package.

NDC VARCHAR2(20) The NDC number for the drug.

STRENGTH NUMBER(14,4) The strength of the product.

STRENGTH_UNIT

VARCHAR2(50) The unit associated with the strength of the product.

Product Labels



3. Select the Packaging tab.

The Packaging tab displays.

4. Highlight the Packaging record to be removed and press the Delete Record button or select Edit=>Delete Record.


5. Click the Save button or select File=>Save to save changes.


Product LabelsThe label form allows you to view and maintain product labels. Each label has a user defined name. The versions of a label are identified by a sequential version number. Associated with each version is an effective date. The label maintenance form is designed to allow the user to make label changes in conjunction with a new MedDRA version. It can also be used outside the context of a MedDRA update.

The label maintenance form has three panels. The summary panel displays a list of all labels in the navigator bar and information about the label and its version is located in the center region. The Detail panel shows the expected event terms for the label and its version. It includes the current terms and optionally the pending changes. When used in conjunction with a MedDRA update, it shows how label terms are affected by the update. The Activate panel allows the user to control the activation of pending changes.

The data behind the linking of expected terms to a label is stored in TMS. The label itself is a term in a TMS dictionary containing a single level. MedDRA terms that are included in the label are indicated in TMS using links between the MedDRA term and the label name. An adverse event is expected when there is a link between the MedDRA term and the label term. These links are called Named Relations in TMS. For more information, see "Label Qualifications".

Pending label changes are stored in a TMS predict group. Activation moves the changes from the predict group to the production dictionary. The label maintenance form allows the user to select a Pre-Dict group. When used in conjunction with a MedDRA update, the label changes and the MedDra changes should be staged in the same Pre-Dict group.

Creating a New LabelNew labels are created in the Global Maintenance subsystem, provided you have administrator privileges. To create a new label:

1. Launch the Label Maintenance screen by selecting File=>Label Maintenance from the Main Menu, or by clicking the Label Maintenance button on the toolbar.

2. Click the Add Record button on the toolbar or select Edit=>Add Record from the Main Menu.

3. Enter the new Label Name and description of the label. Select a Pre-Dict group from the drop-down menu. Select a Dictionary from the drop-down menu.

4. Click the Save button on the toolbar.

The new label appears in the Navigator panel.

Product Labels


Creating a New Version of a LabelOnce a label is created, you can create a new version of that label. Label versions are implemented using TMS versioning.

To create a new version of a label:

1. From the Navigator panel, select the latest version of the label. This is the first record listed in the Label Versions area.

2. Click on the Details button.

The Label Details dialog box displays.

3. Select the Pre-Dict group from the drop-down menu and click OK.

The Label Details screen displays. You can modify any existing relations, add event terms, or add relations to that label.

4. Click the Save button to save to the Pre-Dict group.

5. Click Exit.

Viewing Label VersionsTo view the versions of a label:

1. From the Product Labels screen, highlight the label in the Navigator panel.

All versions of the label populate in the Label Versions area.

2. Highlight the label version and click Details to view more details related to the label.

3. Click Summary to return to Product Labels or click Exit to return to Global Maintenance.

Adding Event TermsTo add additional event terms to the Label Details form:

1. Place the cursor in the Label Details area and click Add Record.

A new record is created.

2. Double-click in the new record.

The MedDRA Terms dialog box displays.

3. In the Find field, enter a partial value to limit the list, or % to see all values.

4. Click Find.

5. Highlight the selection and click OK.

You return to the Label Details screen. The Event Term field is populated with the term you selected. The Code field displays the MedDRA code for the term. The Level field displays its level of hierarchy.

Label QualificationsAERS supports qualified terms in a label. A qualified term is expected if some condition of the case data is true. For example, an event might be expected in a drug interaction but unexpected if the drug is taken alone. The test for the qualification are against data that appears in the case. The following table displays the types of qualifications supported in AERS. Each type of qualification is supported by a different named relationship in TMS.

Product Labels


Activating a LabelWhen you activate a label, you apply all pending changes in the TMS Pre-Dict tables, as well as apply changes to the appropriate AERS tables, to create the new label versions. It is typical that when a MedDRA update is being applied, a Pre-Dict group can contain updates to many labels.

To activate a label:

1. From the Product Labels screen, highlight the Label Version and click the Activate button.

The Activate Labels screen displays.

2. Select the Pre-Dict group from the drop-down menu. Update the screen using the following buttons and fields:

Qualification Name Named Relationship Name Data Test

No qualification KNOWNAENA N/A

Overdose OVERDOSE AE_SUSPECT_DRUGS.OVERDOSE_FLAG using RPT decode

Interaction INTERACTAE AE_SUSPECT_DRUGS. DRUG_INTERACTION_FLAG using RPT decode

Death NONFATALAE NOT (AE_EVENTS. DIED_FLAG) using RPT decode. A null implies a non-fatal event

Severe MILDAE AE_EVENTS.SEVERITY use submission wizard decode

Field / Button Result

All Product Labels Checkbox. If selected, retrieves all labels listed on the Product Labels screen.

Pre-Dict Labels Checkbox. If selected, retrieves only the labels assigned to the Pre-Dict group selected from the drop-down menu.

Get Labels Button. Clicking the Get Labels button populates the Label Name field.

Clear All Button. Clicking the Clear All button clears all labels.

None Button Clears all selected labels.

Create New Version Checkbox. If selected, a new version for the selected label is created.

All Button. Selects all labels.

Effective Date The date that is added to the new version or updated in the latest version.

Update Drug Approvals If selected, updates the DRUG_APPROVALS table.

Reason Text field. The code that is used for the label change reason.

Comment Text field. The comment associated with the code.

Product Labels


3. Select the Check radio button and click Run to run the TMS check mode.

■ When you select Check=>Run, the Activation dialog box appears asking if you want to proceed to check activation of pending label changes in the pre-dict group in TMS. Click Yes.

4. Select the Activate radio button and click Run to activate the label.

■ When you select Activate=>Run, the Activation dialog box appears asking if you want to proceed to activate pending label changes in the pre-dict group in TMS, and update the selected label records.

5. Click Summary to return to the Product Labels screen, or click Exit to close the screen.

Copying an Existing LabelYou have the ability to copy an existing label. If you choose to copy an existing label, you can choose any label version defined against MedDRA for the latest domain. When you copy an existing label, the Pre-Dict records needed are copied into the Pre-Dict tables.

To copy an existing label:

1. Launch the Label Maintenance screen by selecting File=>Label Maintenance from the Main Menu, or by clicking the Label Maintenance button on the toolbar.

The Label Maintenance screen displays.

2. Highlight the Product Label you wish to copy in the Navigator panel.

3. Click the Copy Label button.

The Copy Label dialog box displays.

4. Enter the New Label name and a description of the new label. Select a Pre-Dict group from the drop-down menu.

5. Click Create.

The Label Copied dialog box displays notifying you that the new label was created. Click OK. The new label appears in the Navigator panel.

Apply to Selected Labels Button. Clicking the Apply to Selected Labels button applies the date to the effective date to any selected labels.

Field / Button Result

Product Labels


Maintaining the AERS-TMS Dictionary 6-1

6Maintaining the AERS-TMS Dictionary

This chapter provides a high-level overview of the AERS-TMS dictionary implementation and instructions on how to perform routine TMS maintenance activities required to use TMS with AERS and to take advantage of the AERS-TMS integration.

Conceptual OverviewOracle AERS 4.5.2 uses the Oracle Thesaurus Management System (TMS) to manage the standard nomenclatures required for adverse event reporting (MedDRA for adverse events and diseases/diagnoses and WHO-DRL for products). Oracle AERS has specific dictionary structure and configuration requirements. The AERS-TMS Dictionary load installation step creates the required TMS structure and loads data into the dictionary.

AERS-TMS MedDRA ImplementationAERS uses the MedDRA terminology for coding adverse events, diseases and diagnoses, and other terms as required by international regulations. The MedDRA Dictionary is licensed independently from Oracle AERS, but the AERS Installer includes an installation path that allows you configure TMS and upload MedDRA into the AERS-TMS dictionary. The default MedDRA implementation that is installed with AERS (in the AERS-TMS Dictionary Load step, See the Installation Guide) is referred to as a “primary path” implementation of MedDRA. In the AERS implementation, each Low Level Term (LLT) in the dictionary is linked to one and only one Preferred Term (PT), which is in turn linked to only its “primary” System Organ Class (SOC) based upon the primary path indicators provided by the MSSO. This primary path also identifies a single high Level Term (HLT) and High-level Group Term (HLGT) for each LLT. AERS uses the primary path for all visual display, ad hoc query, and reporting purposes.

AERS-TMS WHO Drug ImplementationOracle AERS uses product dictionaries to manage the association between trade names and preferred names and ingredients for reporting and ad hoc querying purposes. The default product dictionary that is installed with AERS is WHO Drug. The WHO Drug Dictionary is licensed independently from Oracle AERS, but the AERS Installer includes an installation path that allows you configure TMS and upload WHO Drug into the AERS-TMS dictionary. The default configuration of the WHO Drug includes the standard WHO Drug objects (Trade Names, Preferred Names (Regulatory Group Name), Ingredients, ATC Levels), and also includes some AERS-specific entities and attributes. These additions are designed to enhance the functionality within AERS as

Adding Company Products


well as simplify the management of the AERS Company Product Repository (see "Company product repository" on page 2-1).

Regulatory Group NameThe Regulatory Group Name is an arbitrary entity that corresponds directly to the product name in the Company Product Repository. This additional entity allows companies to flexibly associate products to the AERS Company Repository and should simplify the repository management over earlier version of AERS. Regulatory Group names can have a relationship to a Preferred Name, a Trade Name, or a Company Product Name.

Company Product NameThe Company Product Name is an AERS-specific entity that is added to the dictionary to help manage products that do not easily fit into the WHO Drug hierarchy. A good example of this is a medical device.

Product TypeThe AERS Product Type is an AERS-specific attribute of a Preferred Name (Regulatory Group Name), Trade Name, or Company Product Name. It is designed to classify the product as a drug, device, or vaccine. These classifications are necessary in AERS as they drive reporting features. Valid entries are: DRUG, DEVICE, VACCINE.

Blinded Therapy FlagThe Blinded Therapy Flag is an AERS-specific attribute of a Preferred Name (Regulatory Group Name), Trade Name, or Company Product Name. It is designed to classify an entry in WHO_DRUG as either a Blinded Therapy entry or a Placebo entry. These values are in turn used by some of the regulatory reports (particularly those used for reporting clinical data) to classify and group cases based upon type of treatment. Valid entries are B (for Blinded Therapy) and P (for Placebo).

Adding Company ProductsEach product that you are required to report to regulatory agencies or your partners must be represented in the AERS Company Product Repository and must have corresponding entries in the AERS-TMS dictionary. The details for managing the



Company Product Repository can be found in "Company product repository" section on on page 2-1. This section outlines the decision criteria and steps necessary to ensure that the relationship between the AERS Company Drug Repository and the AERS-TMS Dictionary is correct and supports your business needs.

The critical decision criteria are:

■ Is the product already listed in WHO Drug?

Most commercial products are present in WHO Drug and therefore available for configuration. A product is absent from WHO Drug for several reasons, including, it is newly launched and has not been added, it is a research compound and is therefore unknown to the WHO Drug maintenance organization (the Uppsala Monitoring Centre), or because it is a medical device or chemical compound not included in the WHO Drug nomenclature.

■ If the product is listed in WHO Drug, are all of the trade names or other identifiers present in the dictionary and correctly associated with the Regulatory Group Name that you use to report the product.

■ Is the granularity of the WHO Drug representation of your product sufficient to reflect the reporting and management requirements you have for the product?

Adding products to the AERS-TMS dictionary The following instructions pertain to adding all of the types of entries in the dictionary. The specific steps you take depends on what you are adding. This example covers adding a brand new entity, from Regulatory Group Name, Preferred Name, and Trade/Company Names.

To add an entry to the AERS-TMS Dictionary:

1. Log on to TMS as a user with dictionary maintenance rights.

2. Select Repository Maintenance=>Maintain Repository Data.

The Choose Domain screen appears.

3. When prompted, select Domain LATEST and the Dictionary WHODRUG (or whatever short name was assigned to the drug dictionary during the AERS-TMS Dictionary Load).

The Maintain Repository Data screen appears.

4. It is recommended that you create a new Activation Group for maintaining your additions. If you have already created an Activation Group, skip to step 5.

■ Place cursor in the Activation Group field and press the Add Record button.

■ Enter a Name (such as AddCompanyProducts) and description.

■ Place the cursor in the Short Name field of the Dictionaries within this Activation Group and select the WHO Drug dictionary.

■ Save the new record by pressing F10 or pressing the Save button on the toolbar.

The newly created Activation Group appears in the Navigator panel.

5. Expand the Activation Group.

Two dictionary groups appear under the WHO Drug dictionary entry: One labeled Anatomical-Therapeutic-Chemical (ATC) Classification Group and the other labeled Verbatim Term Classification Group. The dictionary maintenance functions described below should take place within the Verbatim Term Classification Group.



Adding a New Regulatory Group NameYou need to add a new Regulatory Group Name if you are creating a new entry in the AERS Company Product Repository or if there is no Regulatory Group Name in the AERS-TMS Dictionary corresponding to a Company Product.

If you are adding a new Regulatory Group Name, follow these instructions

1. Click on the Regulatory Group Name branch within the Verbatim Term Classification Group. The detail screen refreshes and the Regulatory Group Name block appears in the middle of the screen.

2. Place the cursor in the Regulatory Group Name field and enter the Regulatory Group Name.

3. Optionally, enter a Drug ID and a Comment.

4. Press Save to save the new Regulatory Group Name

Adding a New Preferred NameYou need to add a new preferred name whenever you are adding a drug, vaccine or biologic that does not already exist in WHO Drug or if you want to re-map existing drugs into different preferred names than those present in the commercial WHO Drug dictionary. You can use a preferred name/trade name relationship for devices, but usually it is sufficient to manage devices with just a Regulatory Group Name and a Company Product Name.

If you are adding a new preferred name, follow these instructions

1. Click on the Preferred Name branch within the Verbatim Term Classification Group. The detail screen refreshes and the Preferred Name block appears in the middle of the screen

2. Place the cursor in the Preferred Name field and enter the desired Preferred Name. This name must be unique.

3. Optionally, enter an Drug ID and a Comment.

4. Enter the AERS Product Type (DRUG, DEVICE, VACCINE) and Blinded Therapy Type (B for blinded therapy, P for placebo).

5. Press Save to store the new Preferred Name

6. If you are creating an association between the Regulatory Group Name and the Preferred Name (the most common configuration), you must create the Relationship using TMS:

■ Click on the Regulatory Group Name branch within the Verbatim Term Classification Group.

The screen refreshes and the cursor is positioned in the Regulatory Group Name field.

■ Press F7 to enter query, enter the name of the Regulatory Group Name, and press F8 to find the Regulatory Group Name.

■ Enter the preferred name in the Term field in the top block and press Tab. The preferred name details appear.

■ Press Save again to store the relationship.

Assigning an existing Preferred Name to your Regulatory Group NameIf your company product already has a preferred name in WHO-DRUG, you can associate that existing name with your Regulatory Group Name.



To assign an existing preferred name, to a Regulatory Group Name, follow these instructions


2. Press F7 to enter query, enter the name of the Regulatory Group Name, and press F8 to find the Regulatory Group Name.

3. Place the cursor in the top block in the Term field and enter the Preferred Term Name. This creates a parent-child relationship between the preferred name and the Regulatory Group Name.

4. Press Save again to store the relationship.

Adding a New Synonym (Trade Name) If your product is marketed under multiple trade names, you can add each of them to the dictionary and create relationships between the trade names and the preferred names or, if desired, from the trade names and the regulatory group name. It is most common to create a Trade Name - Preferred Name association, however, you can create a direct link between a Trade Name and Regulatory Group Name.

To add a new trade name:

1. Click on the Synonym branch within the Verbatim Term Classification Group. The detail screen refreshes and the Synonym block appears in the middle of the screen

2. Place the cursor in the Synonym field and enter the desired Synonym name. This name must be unique

3. Optionally, enter a Drug ID and a Comment.


5. Press Save to save the new Synonym.

6. To create the relationship between the Synonym and the Preferred Name, place the cursor in the top block in the Term field and enter the Preferred Name. This creates a parent-child relationship between the Preferred Name and the Synonym.

Press Save again to store the relationship.

7. If you do not create a Preferred Name-Trade Name relationship, or if the Preferred Name is not associated with a Regulatory Group Name, then you need to create a direct association between the Synonym and the Regulatory Group Name in order to process cases for the product. To create a relationship between a Synonym and a Regulatory Group Name:




■ Enter the Synonym in the Term field in the top block and press Tab. The Synonym details appear.




Assigning an existing Synonym (Trade Name) to your Regulatory Group NameIf your company product already has a trade name in WHO-DRUG, you can associate that existing name with your Regulatory Group Name. Note: You only need to do this if there is no association between the preferred name for the product and the Regulatory Group Name. For example, if there are multiple manufacturers for a product (once generics are available or it is OTC), you may want to associate only your trade names with your company products. In this instance, you create the associate between Regulatory Group Name and the trade name.

To assign an existing trade name, to a Regulatory Group Name, follow these instructions


2. Press F7 to enter query, enter the name of the Regulatory Group Name, and press F8 to find the Regulatory Group Name.

3. Place the cursor in the top block in the Term field and enter the Synonym name. This creates a parent-child relationship between the Synonym and the Regulatory Group Name.

4. Press Save again to store the relationship.

Adding a New Company Product NameThe AERS-TMS Dictionary implementation allows you to create non-WHODRUG entries referred to as Company Product Names. Company Product Names can be used from new research compounds where a internationally recognized generic name has yet to be assigned, or any other circumstance where the traditional trade name-preferred name relationship does not hold true (such as for medical devices). You can also use Company Product Names to manage proprietary nomenclatures or other company-specific differentiators not tracked in the commercial WHO-Drug, like concentrations.

To create a Company Product name, follow these instructions

1. Click on the Company Product Name branch within the Verbatim Term Classification Group. The detail screen refreshes and the Company Product Name block appears in the middle of the screen.

2. Place the cursor in the Company Product Name field and enter the desired Company Product Name. This name must be unique

3. Optionally, enter an Drug ID and a Comment.


5. Press Save to save the new Company Product Name

6. If you are creating the association between the Regulatory Group Name and the Company Product Name:




Using TMS Domains


■ Enter the Company Product Name in the Term field in the top block and press Tab. The Company Product Name details appear.


7. To create a relationship between the Company Product Name and a Trade Name (Synonym), place the cursor in the top block in the Term field and enter the Synonym. This creates a parent-child relationship between the Synonym and the Company Product Name.

Press Save again to store the relationship.

Activating your newly added dictionary termsOnce you have added all of your company dictionary terms, you must “activate” them so that they auto-encode from Oracle AERS. The activation process adds the terms to the product dictionaries.

To activate your terms:

1. Log on to TMS as a user with dictionary maintenance rights if you are not already.

2. Select Repository Maintenance=>Maintain Repository Data.

The Choose Domain screen appears.

3. When prompted, select Domain LATEST and the Dictionary WHODRUG (or whatever short name was assigned to the drug dictionary during the AERS-TMS Dictionary Load).

The Maintain Repository Data screen appears.

4. Select the activation group you used when adding your company products.

5. Select the Transfer Data command from the Options menu.

This activates your newly adding dictionary terms, transferring them to the production dictionaries.

6. Close the Maintain Repository Data screen and exit TMS.

Using TMS DomainsA Domain is a TMS object that defines a particular dictionary version or subset. Domains can be used in AERS to create project-specific (or customer-specific) dictionaries and also to manage a dictionary version if you need to, for example, maintain multiple active versions of MedDRA. By default, AERS always uses the “latest” dictionary unless you have applied rules that specifically associate a domain.

Creating a Domain in TMSTo create a Domain you use the TMS Maintain Domain Screen.

To add a Domain to the AERS-TMS Dictionary:

1. Log on to TMS as a user with dictionary maintenance rights.

2. Select Maintain Domain from the menu tree.

3. Expand the Activation Group.

Mapping cases to a TMS DomainOnce you have defined a domain in TMS, you can create rules that associate that Domain with a subset of cases. The criteria for assigning a domain include Case Type,

Creating and using TMS Search Objects


Product, Study. With these criteria, you can establish rules that associate a particular domain to a product (useful for CROs working with multiple customers or a company with project-specific dictionary requirements), a particular study (useful if you began a study on a particular version of MedDRA and want to continue coding in that version). You can also use Case Type as criterion for defining a Domain. Domain mapping is defined in the AERS Global Maintenance subsystem.

To add a Domain mapping to the AERS:

1. Log on to the Global Maintenance subsystem as a user with access to the Domain Mapping tab.

2. Place the cursor in the Domain ID field and enter a Domain ID or select a Domain ID from the List of Values. When you select an ID, the Domain Name appears.

3. Enter the case criteria for the mapping. Enter Case Type, Product, and/or Study.

4. Press Save to create the mapping

If you add or change a Domain Mapping rule that affects existing cases (for example, you change the domain for a study), you need to run Batch Reclassify for the cases. See the Section , "Running Batch Reclassify" to reclassify a list of cases.

Creating and using TMS Search ObjectsA search object is a set of rules that define how the auto-encoding and querying activities behave when searching for dictionary terms. Search objects can be simple (like wild cards) or complex algorithms that use context-sensitive search feature of InterMedia. A search object can apply to the auto-encoding algorithm (allowing you to use the search objects to increase the likelihood of finding a dictionary terms). Search objects can also serve as starting points for searching the dictionary when coding omissions.

To create Search Objects, please follow the instructions included in the TMS Users Guide.

Running Batch ReclassifyBatch Reclassify reapplies the autoencoding rules for a case, case list, or all of the cases in AERS.

To reclassify a case of a list of cases, you can run the Batch Reclassify Report from within AERS.

1. Log on to AERS as a user with access to the Batch Reclassify Report.

2. Create a case list with the cases that require reclassification.

3. Navigate to the Reporting subsystem.

4. Expand the Data Management folder.

5. Double-click on the Batch Reclassify report and enter the Case List name (or Active). or enter Y in the All Cases to reclassify all of the cases in AERS.

6. Click Run.

To run Batch Reclassify for all of cases in the AERS database:

1. Log on to SQL*Plus as the AERS schema owner.

2. To run the procedure directly, enter the following commands:

SQL> set serveroutput on

Running Batch Reclassify


SQL> insert into process_queue (queue_id) values (-1);

SQL> insert into rtemp (queue_id, case_id, qry_sts) select -1, case_id, ’0’ from ae_cases;

SQL> commit;

SQL> declare n1 number; n2 number; begin aers_dictionary_api.batchreclassify(-1,'BR','N','Y',n1,n2); dbms_output.put_line('Cases Processed: ' || n1); dbms_output.put_line('Terms Processed: ' || n2); end; /

SQL> delete from rtemp where queue_id = -1;

SQL> delete from process_queue where queue_id = -1;

SQL> commit;

3. To run the existing script, which includes the above commands and also queries for errors after the procedure completes, enter the following command:

SQL> @run_batch_reclassify.sql

Note: You may need to set the default directory in SQL*Plus to the OPA_HOME\aers\database\tools\dba directory before running the script.

Running Batch Reclassify


Studies 7-1

7Studies

The section describes how to manage studies.

Maintaining Study AttributesThe function of the study attributes table is to store information about a study. The study attributes table is maintained in the Study Info section of the Studies tab in the Global Maintenance subsystem. The study attributes table includes the following data:

To maintain study attributes:

1. Open the Global Maintenance subsystem and click the Studies tab.

2. To add a new study, follow the instructions in the "Adding Studies" section. To add attributes for an existing study, select the study from the Navigator panel.

3. In the Study Info section, add the study attributes.

4. Click the Save button on the Toolbar.

Column Data Type Description

BLINDED_STATUS VARCHAR2(15) Codelist. The values are B=Blinded and U=Unblinded.

BLINDED_TYPE VARCHAR2(15) Codelist. The values are D=Double-Blind and S=Single-Blind.

CO_SPONSORSHIP_TYPE

VARCHAR2(15) Codelist. The values are A=Description of A and B=Description of B.

EUDRACT_STUDY_ID

VARCHAR2(175) Text field. The Eudract study identifier (European IND number).

STUDY_ID VARCHAR2(175) When you add a new study, the Study ID field populates with the Study name that you create.

STUDY_STATUS VARCHAR2(15) Codelist. The values are C=Closed and O=Open.

STUDY_TYPE VARCHAR2(15) Codelist. The values are C=Clinical Trials, I=Individual Patient Use, and O=Other Studies.

Adding Studies


Study SecurityYou can link Studies to specific Product Codes to create security and distribution rules. The system then assigns the Product Code, with the Study ID, to a Product Group and uses the Product Code to designate Oracle AERS site permissions. You must assign a Study ID with a Product Code. Study IDs may not exist by themselves. Study maintenance is performed in the Oracle AERS Global Maintenance subsystem.

You can also store attributes of a study in the Oracle AERS Global Maintenance subsystem, using the study attributes table. See "Maintaining Study Attributes".

Study ProductsOn the Study Products tab, you can enter the names of the products involved in the study, as well as their role in the stud.

Adding StudiesTo add a study:

1. Select the Study tab from the Oracle AERS Global Maintenance subsystem.

The Study Maintenance screen displays.

2. Click on a blank record and press the Add Row button.

A blank row displays.

3. Key in the fields.


Oracle AERS adds the study to the database.

Updating StudiesTo update a study:



2. Select the study you want to update.



Oracle AERS saves the updates to the database.

Deleting Studies

To delete a study:

Caution: Deleting a study breaks the connection between the Product Code and the Study ID. Study security and distribution rules no longer be in effect. If you have implemented study-level security, users may no longer have access to the study. If your distribution rules include studies any cases containing the deleted Study ID may be removed from your local Oracle AERS site.

Deleting Studies

Studies 7-3



2. Select the study you want to delete.

3. Click the Delete Row button or select Edit=>Delete Record to remove the study.

The study information disappears from the screen


Oracle AERS deletes the study from the database.

Deleting Studies


Product Groups 8-1

8Product Groups

Product Groups are a convenient way to define combinations of Product Codes and Studies for routing and security permissions. A Product Group is a combination of one or more Product Codes and, optionally, one or more Study IDs. A Product Code may belong to one or more Product Groups. You assign Product Groups to particular Oracle AERS sites, User Groups, and Users.

Product Groups can contain an unlimited number of Product Codes; therefore, they act as a shorthand for defining permissions. This grouping eliminates the need to assign Product Codes individually.

Defining Product GroupsYou may define Product Groups by selecting individual Product Codes and studies to belong to a Product Group.

Oracle AERS also provides tokens to simplify defining Product Groups. For example, if you define a Product Group as 'ALL' in the Product Group field, the symbol '*' displays in the Product Code and Study ID fields, representing All Product Codes and All Studies. Designating a Product Group 'ALL' always returns All Product Codes and All Studies. However, you can use the '*' symbol to return All Studies only (without the Product Codes). If applied only to Studies, '*' means all values of Study, including 'Null'. You can use a blank Study ID field to indicate cases without a Study identifier.

Adding Product GroupsTo add a Product Group and associated Product Codes/Studies:

1. Select the Product Groups tab from the Oracle AERS Global Maintenance subsystem.

The Product Groups screen displays the list of Product Groups in the Navigator panel and a specific Product Group and associated Product Codes and Studies in the Object panel.

2. Click in the Product Group Field.

3. If a Product Group is displayed in the field, press the Add Record button or select Edit=>Add Record.

4. Specify a Product Group Name, and optionally, a Description.

Note: Product Group maintenance is performed in the Global Maintenance subsystem.

Updating Product Groups



The new Product group is saved to the database.

6. Place the cursor in the Product Code field for the newly created Product Group.

7. Specify the Product Code and optionally, Study. If the Product Group is for all products and studies, use the asterisk '*' in each field. If the Product Group represents all cases for a Product Code, specify the Product Code and enter an asterisk '*' in the Study field.


The new Product group with its associated Product Codes/Studies is saved to the database.

Updating Product GroupsTo update a Product Group:


The Product Groups screen displays the list of Product Groups in the Navigator panel and a specific Product Group and associated Product Codes and Studies in the Object panel

2. Select the Product Group you want to update from the Navigator panel.

3. Key in the appropriate changes to the Product Group or associated Product Codes/Studies.


The new Product group with its associated Product Codes/Studies is saved to the database.

Deleting Product Groups

To delete a Product Group, you must first delete the Product Codes associated with the group, then delete the group itself:


The Product Groups screen displays the list of Product Groups in the Navigator panel and a specific Product Group and associated Product Codes and Studies in the Object panel.

2. Select the Product Group you want to update from the Navigator panel.

3. Select a Product Code from the details and press the Delete Record button or select Edit=>Delete Record.

The study information disappears from the screen

Caution: Deleting a Product Group may remove all cases associated with that Product Group from the Oracle AERS site, if a particular drug is assigned to only one Product Group. The Master site contains all cases for data recovery if needed.


Product Groups 8-3

4. Once all of the associated Product Codes are deleted, select the Product Group and press the Delete Record button or select Edit=>Delete Record.


The Product Group is deleted from the database.



Configuring AERS for multilingual use 9-1

9Configuring AERS for multilingual use

This chapter covers the multilingual features of Oracle AERS and provides directions for maintaining local language translations of codelists, field and window labels, and error messages.

Overview of multilingual architectureOracle AERS supports local language data capture and reporting for a single database repository. That is, all of the data required for reporting adverse events and product complaints in multiple languages is stored in a single database instance: the information is captured once and reported in the appropriate local language, translated free-text can be stored and reported, and the user interface can be represented in the user’s local language if desired.

While there are a potentially large number of local languages that can be captured and stored in Oracle AERS, practically speaking, the languages that you need to manage your safety data are limited to those countries where you have local reporting requirements and those locations require reporting in their native languages. For example, France, Germany, and Japan require “local” cases to be reported on specialized report forms, in the native language. You may also choose to use some or all of the user interface features in a local language. You can choose to translate only some of the field prompts or messages into a local language (for example, if there was ambiguity in the English terms for an item that are more accurately or clearly represented in a native tongue). Oracle AERS allows you to make these decisions and to maintain the translations yourself, should you desire.

Maintaining AERS Local LanguagesThe list of languages that you support in your environment is defined in a Codelist called LANGUAGE_LIST. This list contains all of the “languages” used by Oracle AERS, including reserved languages (such as RPT, ISO, and MW) as well as local languages used during the capture and management of adverse events and product complaints.

Note: In Oracle AERS 4.5.2, only the user interface for data capture, case data query, and management support local language interfaces. System Maintenance and related screens are not language-sensitive. In addition, not all fields in data entry support the local language decodes. The fields must be designed to support displaying the decode values and the View_Value Flag in Field Attributes must be equal to’Y.’

Setting a User’s Local Language


To maintain the list of available languages:

1. Launch the Global Maintenance subsystem as a user with administration privileges.

2. Select the Codelists tab.

3. Select the codelist named LANGUAGE_LIST from the Navigator panel.

4. Add the desired Language Code field to the codelist details. The convention in AERS is to use the local country code for the language, except for the default language, which is en.

■ Code: Enter the two letter abbreviation used within AERS for the country.

■ Lang Cd: In the field labelled Lang Cd, enter en.

■ User Enterable: This box should be checked by default. This allows the language to be displayed in the Language Code List of Values in User Maintenance and when entering translations for free-text fields in AERS.

5. Save you changes.

Setting a User’s Local LanguageEach AERS user has a default language setting. This value can be set to any language, and if there are local language translations corresponding to the user’s language, the user interface (field labels, value decodes, menus, error messages, etc.) is displayed in that language.

To set or update a user’s language setting:

1. Log on to AERS 4.5.2 as a user with administration privileges.

2. Open the Administrator Console and select the Users tab.

3. Select the user from the Navigator panel.

4. Update the Language Code field to the desired language. The convention in AERS is to use the local country code for the language, except for the default language, which is en.

5. Save your changes.

Maintaining Codelist TranslationsOracle AERS stores local language translations of codelist values such as patient sex or event outcome. These values are used when needed to generate local language reports (such as the BfArM report for the German regulatory authorities) and to display the values of coded fields in the user’s local language during case data entry.

Codelist translations are stored in the Code List Details table, along with the English translations (as well as reserved language values such as RPT values that are used for reporting purposes). To add a new translation or to change and existing translation:

1. Launch the Global Maintenance subsystem as a user with administration privileges.

2. Select the Codelists tab.

3. Select the codelist that contains the values you want to translate from the Navigator panel.

Maintaining Field and Window Label Translations


4. To add a new language translation, place the cursor in the Code List Details area and click the Add Record button on the toolbar. Enter the values:

■ Code: This value is what is stored in the database and is used, along with the language code itself, to translate the values. Enter the code of the en term you are translating.

■ Lang Cd: Enter the two character abbreviation for the country that is used to represent the language (e.g. DE for German, FR for French, JP for Japanese).

■ Code List Value: Enter the local language translation for the item.

■ User Enterable: Check the User Enterable box.

5. To update an existing translation, clink on the record for the Code and Language Code that contains the translation that you wish to update, and change the Code Value Text.


Maintaining Field and Window Label TranslationsField and window label translations are maintained using the Field Attributes form. This form is used to manage all aspects of the workflow and screens/fields configuration in AERS.

Adding Field Label TranslationsTo add field label translations:

1. Log on to the Field Attributes form as the AERS schema owner or a user with administration privileges. Or from Oracle AERS, select Help=>FAT Configuration.

2. Enter a query to find the field that you want to translate by pressing F7, entering the form name (E_ENTRY or QUERY) and other defining attributes. Then press F8.

3. Press the Translate button that is to the right of the Screen Label fields.

4. Enter the local language translation for the field.

■ Language Code: Enter the local language code as created above.

■ Screen Label: Enter the local language translation of the screen label.

■ Field Label: Optionally, enter a local language translation of the field label. This value does not display to the user, but may be useful in clarifying the field should an abbreviation or other nomenclature be used on the screen itself.

5. Save your changes by pressing F10.

6. When you have entered the translations for the field, close the window to return to the Field Attributes form.

7. If you have additional translations, repeat these steps as necessary, otherwise, close the Field Attributes form and save your changes if prompted.

Note: If the field does not have a local language label corresponding to the user’s language settings, the label in the Screen Label field appears during data entry or query.

Maintaining Error Messages and Translations


Adding Window Label TranslationsTo add window label translations:

1. Log on to the Field Attributes form as the AERS schema owner or a user with administration privileges.

2. Press the Define Windows button to display the Window Attributes form.

3. Enter a query to find the window whose label you wish to translate by pressing F7, entering the form name (E_ENTRY or QUERY) and other defining attributes., then press F8.

4. Press the Translate button that is to the right of the Window Label fields.

5. Enter the local language translation for the Window Label.


■ Window Label: Enter the local language translation of the screen label.


7. When you have entered the translations for the window Label, close the window to return to the Field Attributes form.

8. Close the Field Attributes form and save your changes if prompted.

Maintaining Error Messages and TranslationsError messages can also be translated into your user’s local languages to assist in the usability of Oracle AERS.

Adding Error Message TranslationsTo add field label translations:

1. Log on to the Field Attributes form as the AERS schema owner or a user with administration privileges.

2. Press the Define Error Messages button on the bottom right corner of the screen.

3. Find the Error Code that you want to translate by pressing F7, entering your query criteria, and pressing F8.

4. Enter the local language translation for the error message.


■ Error Message: Enter the local language translation of the error message.

Note: If the field does not have a local language label corresponding to the user’s language settings, the label in the Window Label field appears during data entry or query.

Note: If the error message does not have a local language label corresponding to the user’s language settings, the message in the User Err Msg field appears to the user.




6. When you have entered the translations, close the window to return to the Field Attributes form.

7. Close the Field Attributes form and save your changes if prompted.



Supporting your work processes 10-1

10 Supporting your work processes

Oracle AERS manages the lifecycle of your cases through a combination of Active Workflow and Action Items. The system represents a work process as a series of tasks that users perform on a case. Each task has a corresponding set of screens and fields that users complete during that task. The Active Workflow component moves a case through a series of case status transitions based upon the completeness of the task (a decision that the user makes when exiting a case). You assign each user a set of workflow tasks that they perform and an Active Inbox that is based upon a set of saved queries that select cases based upon case status or other selection criteria.

The process for establishing the core Oracle AERS workflow configuration is:

1. Map your work process following the life of a case from receipt to final reporting. When mapping the flow, consider clinical vs. spontaneous handling, expedited vs. periodic reportable, and departmental hand-offs. This information is used to develop the workflow tasks and case status transitions.

2. Identify constraints between workflow steps and case status transitions. AERS allows you to define available workflow steps for each case status (for example, Case Review cannot be performed on a case unless it is in Data Entry Complete status) and the available statuses for each workflow step (for example, a user may not put the case into Closed Status after completing Initial Data Entry).

3. Identify the organizations responsible for each task or groups of tasks. At this level, consider the broader organizational boundaries (Safety, Regulatory, Clinical, etc.). This information is key to establishing both the structure of the User Groups and Users as well as the major workflow steps (if a case crosses organizational boundaries in its lifecycle, it is likely that you create a discrete workflow task on either side of the transition).

4. Identify divisions of labor based upon product or product type (e.g. Drugs, Devices, Vaccines). Do certain groups or individuals within groups focus on specific products.

5. Identify the data elements that are captured at each task in the process.

Case statusesOracle AERS automatically advances the case through a series of customer-defined case status transitions based upon the workflow task that is being performed and the completeness of the task. You have complete flexibility over the case statuses used in your configuration.

To define your cases statuses:

1. Select the Codelists tab from the Oracle AERS Global Maintenance subsystem.

Case statuses


The Codelists screen displays the list of Codelists in the Navigator panel.

2. Select (highlight) the Case Status codelist name from the Navigator panel.

A special Codelist Details screen display in the Object panel.

3. Key in fields:

■ Code

■ Short Value

■ Long Value

■ Language: en

■ Retired

■ Customizable

■ User Enterable

■ Init Case Status: This flag defines the initial case status for the case if cases are created using an ambiguous workflow task. This feature is rarely used in this release.

■ Next Workflow Step: This field identifies the next workflow step that is required for the case based upon its current case status. The Next Workflow Step must currently be updated in SQL*Plus using a simple UPDATE statement when connected as the schema owner.


Oracle AERS deletes the Site from the database.

Optionally, you can further refine your case statuses by defining the set of acceptable workflow steps that can be performed on a case when it is in a particular status. For example, if a case is in Data Entry Complete Status, you may want to configure AERS such that the only workflow step that can be performed is Medical Review. To do this, you would create or update the record corresponding the that cases status/workflow combination in the DE_MODE_STATUSES table.

1. Connect to SQL*Plus as the AERS site schema owner.

2. Insert appropriate records into the DE_MODE_STATUSES table. The columns in the tale are:

DE_MODE: The Workflow step being defined

STATUS: The Case Status being defined

ALLOWED_FOR_NEXT_STATUS: Whether the Status being defined in as acceptable status for a user to select when exiting a case.

MODE_ALLOWED_FROM_STATUS: Whether the workflow step is available given the current status of a case (See Defining Case Statuses above).

A sample SQL statement for the above scenario would look like this:

insert into DE_MODE_STATUSES

(DE_MODE, STATUS, ALLOWED_FOR_NEXT_STATUS, MODE_ALLOWED_FROM STATUS)

values

Document templates


(’MEDICAL-REVIEW’,

’DE COMPLETE’,

NULL,

’Y’);

3. Commit your changes.

Action itemsAction Items represent specific tasks that you can temporarily assign to a case based upon a specific need. Once assigned, they serve as "ticklers" for actions such as requesting follow-up, performing site visits, receiving data clarification, and forwarding a product complaint to manufacturing. Action Items are fully configurable, and you manage them as a codelist. To update the list of Action Items for your work process, see "Data management" on page 12-1.

Document templatesA common use for Action Items is to track correspondence such as Phone Calls, Site Visits, and Follow-up letters. Oracle AERS supports the ability to generate standard letters or correspondence, which can include case data. This feature is supported by create PL/SQL Server Pages, which are then loaded into the database and managed as stored procedures. The user can then click on the Generate Letter icon to see a list of standard templates available, then generate a letter for the active case.

To add new templates you must:

1. Develop the template according to the rules below

2. Save a read-only copy of the template in a standard area.

3. Add a record in the LETTERS table corresponding to the new template.

Creating the template PL/SQL The basis of the document template feature is a set of PL/SQL Server Pages (PSP), created using a specific syntax to allow data from the case to be substituted into the template and displayed in a browser window.

To create the PL/SQL Server Page:

1. Review the sample letters included with Oracle AERS 4.5.2. These can be found in the \aers\server\schema\is\psp directory of the staged installation files used to support an installation. If these files are no longer on your file server, you need to perform a "Server Installation" of Oracle AERS.

2. Once you have reviewed the sample templates, you may either edit the template that best fits your requirements or you can simply create your own.

Note: These instructions assume a solid working knowledge of PL/SQL and HTML. Oracle AERS 4.5.2 includes examples of several different templates to help you get started developing your specific templates.

Document templates


If you are creating a new template, please note that Oracle has adopted a standard of prefixing the procedure name with "LETTER_" so the defined procedure is uniquely identifiable within the database after loading.

Templates can be optionally passed two parameters: The current contact sequence number (if Contact addressing is being used) and the Case ID. Most templates use both.

3. As you are developing, you can load and test your template using the instructions below.

Loading the templateOnce the PSP package is created, it must be loaded into the database instance.

1. Save the program in a secure directory according to your internal change control policies.

2. Load the PSP program into the AERS database instance:

loadpsp -replace -user <connect string> <program name>.psp

For example:

loadpsp -replace -user aers1/aers1@aers45 AECaseSummaryListing.psp

Defining the template in the LETTERS tableThe final step is adding an entry in the LETTERS table to define the new template to Oracle AERS. This step is performed from the Administrator Console within Oracle AERS.

The entry in the LETTERS table must be made at each site.

1. Launch Oracle AERS using an account with administration privileges.

2. Navigate to the Administrator Console by selecting the subsystem icon or selecting Administrator Console from the Maintenance menu.

3. Select the Letters Templates and complete the information as follows:

Display Number: The overall sequence number for the display of the templates within the Generate Template dialog box presented to the user.

Letter Name: The name of the template, as displayed to the user in the Generate Template dialog box

Procedure Name: The name of the stored procedure as loaded into the database (step 2 of Load the template, above)

Cont Seq Nbr: An optional parameter if the template has been designed to accept the Contact Sequence Number as an input variable.

Case ID: An optional parameters if the template has been designed to accept Case ID as an input parameter.

Role: The AERS Application Role required for a user to generate the template.

Category: The name of the Folder that contains the template in the Generate Template dialog box.

Workflow tasks


Workflow tasksWorkflow Tasks are used to move a case through the major steps in its life history. A Workflow Task consists of status transition information and a set of screens and fields that are accessed in that task. Workflow Tasks configure Data Entry forms to optimize screen flow. Most Oracle AERS clients configure the Workflow Tasks so each discrete job uses a separate mode. Examples of discrete jobs include: logging in of cases, data entry of cases, tracking submissions, and case assessment. The attribute components can be configured differently for each of the jobs so that they can be accomplished efficiently and with the least amount of errors.

For each Workflow task, you define two case statuses that control the progress of the case through the workflow. You must make a decision about whether to progress to the next step or remain in the current step when you exit the case, and Oracle AERS presents you with the Task Completed? dialog box.

1. Status on Completion: The case status that the case is assigned if the user indicates that they have completed the Workflow Task by pressing the Yes button in the Task Completed dialog. If this field is left NULL, then the case status does not change if the user selects this option in the dialog box.

2. Status when Incomplete: The case status that the case receives if the user indicates that they have not completed the Workflow Task by pressing the No button in the Task Completed dialog box.

In addition to these default status transitions, you can also define a set of acceptable status transitions for each workflow step.

For each Workflow Task, you may configure a number of data capture elements. The processes for managing these aspects of workflow configuration are discussed in the following sections: Designing Screens and Fields, Data Management, and Edit Checks.

Workflow attributes:

1. Initial Window=>Field.

The default first window for a given Workflow Task is defined in DATA_ENTRY_MODES.FIRST_WDW. The default cursor location for a given Workflow Task and window is defined in WINDOW_MODES.CUR_DFLT_CURSOR_LOCTN.

2. Enabling/Disabling of Update Only Mine ownership security.

Enabling/Disabling Update Only Mine security is defined in DATA_ENTRY_MODES.ENF_OWNERSHIP_SECURITY_FLAG.

Note: Each user is assigned a set of workflow tasks that they can perform. The user has a default Workflow Task, but is also given the option of changing tasks when they open a case for update. The Data Entry form maintains a global variable, which contains its current operating Workflow Task. Whenever the form is activated, the variable checks to see if the user-requested Workflow Task and the current Workflow Task are different. If the Workflow Tasks are different and data entry has unapplied changes, Oracle AERS prompts the user to save the changes before switching Workflow Tasks. The form then reloads the FAT and WAT, switches the first window for the selected Workflow Task, and re-initializes the field attributes. The FAT and WAT are also read and attributes reapplied when the user switches between updating existing cases and entering new cases.

Workflow tasks


3. The Default Modification reason and code list value representing the reason.

The default reason code and reason for a given Workflow Task is defined in DATA_ENTRY_MODES.REASON_CD and DATA_ENTRY_MODES.REASON_TEXT.

Screens and Fields attributes:

1. Next/Previous Window Sequence.

The next/previous window sequence for a given Workflow Task is defined in WINDOW_MODES.NEXT_WDW.

2. Enabling/Disabling a tab or sub-tab.

Enabling/Disabling screen for a given Workflow Task is defined in WINDOW_MODES.DISABLED_FLAG.

3. Field Tab Order.

The next navigable item for a data entry field is defined in FIELD_MODES.NEXT_NAVG_FIELD.

4. Hidden/Enterable Field Attributes.

Hiding/Disabling a field is defined in FIELD_MODES.HIDDEN_FLAG and FIELD_MODES.DISABLED_FLAG.

Data Management/Edit Check Attributes:

■ Edit checks.

Firing of edit rules are dependent on the Workflow Task. The Workflow Task that enable an edit rule are defined in RULE_FIRING_MODES.DE_MODE and RULE_FIRING_MODES.RECORD_STS.

Defining Workflow tasksPrerequisites:

■ Workflow modeled to reflect the discrete steps that are managed through the life of a case. Usually these boil down to 3-6 steps that are in turn modeled as Workflow Tasks.

■ Case Statuses defined.

■ Change Reasons must be defined.

■ Oracle AERS Admin Setup program run to install configuration tools on your computer.

Workflow Tasks are defined in the DATA_ENTRY_MODES table in the Field Attributes form. For each Workflow Task, clients may further configure two sub-modes: 'N' for entering a new case and 'U' for updating an existing case. In order for a user to have the ability to enter a new or update an existing case, the sub-mode must be selected. A Workflow Task without 'N' as a sub-mode indicates a user cannot create a new case in that Workflow Task.

For example, in the DATA_ENTRY_MODES table, if there is a Workflow Task with 'U' as the only sub-mode, a user cannot create a new case by using that Workflow Task. The New Case, Copy Case menu option, and New Case icon would not be available to a user while performing that task.

To create a new Workflow Task:

Workflow tasks


1. Launch the Oracle AERS Field Attributes form by selecting Help=>FAT Configuration from Case Browse.

2. Click the Define Entry Modes button.

The Data Entry Modes screen displays.

3. Click F8.

The existing workflow steps appear in the fields.

4. Click the Insert Record button.

5. Key in the appropriate fields (the column names in the DATA_ENTRY_MODES table are specified in parentheses):

■ New WorkFlow Step (DE_MODE): Workflow Task that is being created. You may be creating the record status pair (update from New) or creating a completely different Workflow Task.

■ New/Update (RECORD_STS): The record status for the Workflow Task that is being created. N (New), U (Update)

■ WorkFlow Label (MODE_DESCRIPTION): Description of the Workflow Task. This label appears in the Case Browse screen if this Workflow Task is the "next step" defined by the case's status.

■ First Window (FIRST_WDW): First window that opens when a user enters this Workflow Task.

■ Enforce Ownership (ENF_OWNERSHIP_ SECURITY_FLAG): 'Y' if ownership security is to be enforced in this Workflow Task. If this flag is checked, User Group Ownership Security is enforced while updating a case in this task.

■ Case Mod Reason Code (REASON_CD): Code describing the default reason for the change while in this Workflow Task. The Reason Code specified here appears in the Modification Reason dialog box

■ Case Mod Reason Text (REASON_TEXT): Text describing reason for the update

■ Status on Incomplete Task (STATUS_ON_INCOMPLETE):

■ Status on Complete Task (STATUS_ON_COMPLETION):

■ Workflow Track (WORKFLOW_TRACK): This field ties together the individual tasks into a "track" that appears on the Action Items screen in the Configuration Wizard. This item must be added via SQL*Plus or from the Data Entry Modes screen from with the Field Attributes Tool.

6. Close the Data Entry Modes screen.


Oracle AERS creates a new Workflow Task. Now you can proceed to modify the configurable aspects of the screen and field configuration, such as visibility and enterability.

Optionally, you can further refine your workflow step by defining a set of acceptable case status transitions that are displayed to a user when they are exiting a case. For example, if upon the completion of medical review, the user must make a decision about whether to close the case (for inclusion in a future periodic listing) or forward the case to regulatory for expedited reporting, you can create two entries for the workflow mode in the DE_MODE_STATUSES table.

1. Connect to SQL*Plus as the AERS site schema owner.

Designing screens


The next/previous window sequence for a given Workflow Task is defined in WINDOW_MODES.NEXT_WDW.

2. Insert appropriate records into the DE_MODE_STATUSES table. The columns in the tale are:

DE_MODE: The Workflow step being defined

STATUS: The Case Status being defined

ALLOWED_FOR_NEXT_STATUS: Whether the Status being defined in as acceptable status for a user to select when exiting a case.

MODE_ALLOWED_FROM_STATUS: Whether the workflow step is available given the current status of a case (See Defining Case Statuses above).

A sample SQL statement would look like this:

insert into DE_MODE_STATUSES

(DE_MODE, STATUS, ALLOWED_FOR_NEXT_STATUS, MODE_ALLOWED_FROM STATUS)

values

(’MEDICAL-REVIEW’,

’CLOSE’,

’Y’,

NULL);

3. Commit your changes.

Assigning Workflow tasks to usersWorkflow Tasks provide security by restricting specific windows and fields from the user (thereby limiting the number of fields to which a user has access).

Workflow Task security is supplied through the use of the USER_ROLES table. By assigning users workflow Tasks in the USER_ROLES table, you assign them permission to perform that particular Workflow Task. The user can only switch to a different Workflow Task in the Options screen or when opening a case if the user has the corresponding User Role defined. User Roles are assigned as part of creating and managing Oracle AERS users (see Chapter 11, "Managing Users And User Groups").

Designing screensThe Oracle AERS data capture screens are highly configurable. The configurable aspects of the data capture screens include global changes, such as validation criteria, field labels, and other data management options, and workflow-specific changes controlling field and window order, field visibility and enter-ability. Screens and fields can also be displayed in the user’s local language (for more information about the multi-lingual features, see "Maintaining AERS Local Languages" on page 9-1). Oracle AERS also includes a set of custom fields that can be displayed to capture customer-specific data elements.

Designing screens


Global screens and fields configurationThe Global aspects of screens and fields configuration can be managed in two ways: The Field Attributes form or using SQL*Plus update scripts. The tool that you chose is up to you. The configuration data is stored in the FIELD_ATTRIBUTES and WDW_ATTRIBUTES tables. These tables define the "look" and "behavior" of windows and fields for the Oracle AERS Data Entry and Query modules. These tables control some of the very fundamental operations of the system and any adverse modifications may jeopardize the normal system functions. In general, customizations should be confined to labels, field value attributes and validation, dictionary mapping, and case and reconciliation status. The following two tables define the configurable attributes of the data entry and query subsystems. Instructions for modifying the attributes using the interactive tools follow the table descriptions below.

FIELD_ATTRIBUTES Table DescriptionThe FIELD_ATTRIBUTES table affects both Query and Data Entry. The general domain of operations affected includes the following: field level edit checking (related to code lists), whether the field is a dictionary field (or not), mapping of the field to a database column, query control, and how the field affects case and reconciliation status.

Table 10–1 Field Attributes Table

Field Name Mod? Description

FORM_NAME N Name of form

BLOCK_NAME N Name of the block on the form

ITEM_NAME N Field on the block/form

WINDOW_NAME N Name of the window

TABLE_NAME N Table name

FIELD_TYPE N Type of field in the Field Attributes Table (FLD or LBL)

FIELD_NAME N Field name

FIELD_VISUAL_ATTR N Stores the base table and item name if the current item is a mirror item: otherwise, field is null.

DATA_TYPE N Defines the data type of the field. Possible values include: CHR (Character), DAT (Date), PDT (Partial Date), BLN (Boolean), LNG (Long), LST (List), and DIC (Dictionary Term)

HELP_CONTEXT_ID N Tag to support the help facility. Use this number when customizing your field help.

RELTD_ITEM_NAME N Stores the base table and item name if the current item is a mirror item. Otherwise, this field is Null

FIELD VALIDATION

CODE_LIST Y Code list, used to populate record group

CODE_LST_SOFT_VAL_FLAG

Y Is validation soft (Y) or hard (N) for code listed fields? Note: This does not apply to the Lists fields in the Quick Query screen (Case List, Study List, Country List, Patient List, Sub Drug List, Proj Drug List, and Prod Code List). For those fields, the validation is always hard

Designing screens


DICTIONARY FLAG Y If this flag is Y, the Data Entry module attempts to map the data entered using the dictionary procedure appropriate for the field. This field can be used by clients to turn the auto-mapping on and off

MANDATORY_TYPE N/A Not implemented. Use Edit Checks to enforce a mandatory field.

MAX_VALUE Y Maximum value for the field

MAX_OVRRD_PRECISION

Y Maximum override precision (number of digits before decimal point). This field also determines the length of a character field

MIN_VALUE Y Minimum value for the field

MIN_OVRRD_PRECISION

Y Minimum override precision (number of digits after decimal point)

MIN_MAX_SOFT_VAL_FLAG

Y Is validation soft (Y) or hard (N) for fields that have min/max values?

VISUAL CONTROLS

CASE_TYPE Y Case type: C (Clinical), S (Spontaneous), NULL [‘ ‘] (N/A)

DEFAULT_VALUE Y Default value used when record is inserted

FIELD_LABEL Y Label of field used in reports and audit functions

SCREEN_LABEL Y Label of field on the screen

FORCE_CASE_FLAG Y Forces the case of field content (i.e., force uppercase). Values: U (Uppercase), L (Lowercase), and M (Mixed Case)

VIEW_VALUE_FLAG Y If True, the values are displayed for this field; if False the codes are displayed

X_POSITION Y X Position of fields on the data entry and query screens (pixels from top left corner).

Y_POSITION Y Y Position of fields on the data entry and query screens (pixels from top left corner).

FIELD_HEIGHT Y Field Height of fields on the data entry and query screens (in pixels).

FIELD_WIDTH Y Field Width of fields on the data entry and query screens (in pixels).

DATA ENTRY FEATURES

RECON_FLD_FLAG Y This flag identifies the field as one that is reconciled with clinical data. If a reconciliation field is modified, the reconciliation status of the case is set to needing reconciliation

ASSMNT_FIELD_FLAG Y Is this field an assessment field (Y/N)? If Y, then a user must have the Assessment Permission in addition to other update permissions to change the field.

DATA_ENTRY_FLD_FLAG

N/A This field is no longer used in Oracle AERS.

Table 10–1 (Cont.) Field Attributes Table


Designing screens


WDW_ATTRIBUTES Table DescriptionThe WDW_ATTRIBUTES table (WAT) provides configuration of the individual window label (name) and its associated on-line help context ID number. In general, modifications to these attributes are not made.

Table containing attributes for each window such as help text and the navigation from one window to the next.

REDE_FLD_FLAG Y This is a critical field. Oracle AERS workflow allows you to define alternative case status transitions if a “critical” or REDE field is updated during the session.

TEXT_EDITOR N/A Not implemented. The text editor for comment fields is controlled by the FORMS_EDITOR entry in the Windows Registry and is set during the product installation.

HELP_TEXT Y Custom help text for field. This feature has not been fully implemented in Oracle AERS.

QUERY FIELDS

MAPPING_ID N Sequence ID for query mapping

DIC_QUERY_TEXT Y Additional query text required for dictionary field with dictionary switches enabled

SUB_QUERY_TEXT Y The additional query text required for fields that are on forms, but not on the database

CUSTOM COMMENTS

CUSTOM_RESTR_TEXT Y Text describing customization restrictions

CUSTOM_CHECK_ PROC_NAME

Y The procedure name if the user has written a process for field validation. If this field is valued, this procedure supersedes all other validation checks

CUSTOM_COMMENTS_TEXT

Y Text describing customization

CUSTOM_PERMSN_TYPE

N Custom permission type S (System), C (Customer may modify)

AUDIT INFORMATION

CREATE_DT S Creation date

CREATE_SITE_ID S Creation site

CREATE_USER_ID S Creation user

UPDATE_DT S Last modified date

UPDATE_SITE_ID S Modifying site

UPDATE_USER_ID S Modifying user

Table 10–2 Window Attributes Table


CURRENT_WDW N Current window. There are entries here for the main windows as well as the subtabs.

Table 10–1 (Cont.) Field Attributes Table


Designing screens


Modifying the global screens and fields configuration attributesTo modify global field attributes using Field Attributes tool:

1. Launch the Oracle AERS Field Attributes form by double clicking the FLD_ATTR.FMX executable in the Oracle AERS folder, or by selecting Help=>FAT Configuration.

The Field Attributes window displays.

2. Query for the appropriate field using standard Oracle Forms query options (see "Basic querying (search) techniques" on page 1-2).

A populated screen returns the Field Attributes records meeting your criteria. Minimally, you should include the Form Name as criteria (E_ENTRY) when querying for Data Entry fields, or QUERY when modifying query fields.

3. Update the fields as desired according to the descriptions in the Field Attributes table above.



To modify global window attributes using Field Attributes tool:

1. Press the Define Windows button on the Field Attributes screen.

The Window Attributes screen appears:

2. Update the fields as desired.

■ Window Label: The label that appears on the tab stop



Revealing custom fieldsThe custom screens and fields are hidden by default, to reveal them follow these directions:

1. From Case Browse, select Help=>FAT Configuration.

FORM_NAME N Form Name for the window (Query, Data Entry, Report)

WDW_LABEL Y Label that displays in the window title bar

MENU_ITEM N/A No longer used in Oracle AERS 4.5. Stores corresponding menu item name for a given window

HELP_CONTEXT_ID N Tag to support the help facility

HELP_TEXT Y Custom help text for window

Note: If the FLD_ATTR.FMX form is not stored on your hard disk, you must run the Oracle AERS Admin Setup program from the Oracle AERS installation CD. This installs the forms you need to perform screen and field configuration.

Table 10–2 (Cont.) Window Attributes Table


Designing screens


The Field Attributes form displays.

2. Click the Enter Query button.

3. Enter E_ENTRY in the Form Name field, and enter %CUSTOM% in the Item Name field.

4. Click the Execute Query button.

The query returns the forty-six custom fields. To scroll through each custom field, use the up and down arrows.

5. For each custom field, enter ’N’ in the Hidden field and ’N’ in the Disabled field.

Workflow-specific screens and fields configurationFor each Workflow Step, you can define which screens and tabs are visible, the flow through those screens and tabs, which fields are visible, which of those are enterable, and finally, the flow (or tab-order) through those fields.

FIELD_MODES TableThe FIELD_MODES table is used to specify Workflow Task-specific field behavior. There must be an entry for every Workflow Task for every data entry record in the FAT.

WINDOW_MODES TableProperties of windows for different Workflow Tasks. There must be an entry for every Workflow Task for every Data Entry window in the WAT.

Note: After revealing the custom fields you must specify the screen location for each field by entering the coordinates in the X Pos and Y Pos fields. By default they are placed in the lower right corner of the screen.

Table 10–3 Field Modes Table


FORM_NAME N Name of form

BLOCK_NAME N Name of the block on the form

ITEM_NAME N Field on the block/form

DE_MODE N Workflow Task

RECORD_STS N Record status in Workflow Task: N (New), U (Update)

DISABLED_FLAG Y Indicates if the field is disabled (displayed but non-enterable in that Workflow step). Y: Field is non-enterable; N: field is enterable.

HIDDEN_FLAG Y Indicates if the field is hidden in the workflow step (DE MODE). Y: hidden; N: visible.

NEXT_NAVG_FIELD Y Next field to navigate to

Configuring the data entry Navigator panel


Modifying Workflow-specific screen and field configurationTo modify workflow specific field and window attributes:

1. Place the cursor in the field you want to modify the attributes for.

2. Launch the Field Attributes form by selecting Help=>FAT Configuration.

3. Do any of the following:

■ To hide a field, enter ’Y’ in the Hidden field on the lower block of the screen.

■ To disable data entry for a field enter ’Y’ in the Disabled field.

■ To return the field to Normal (visible and enterable), enter ’N’ in the Hidden and Disabled fields.

■ To change a Field or Screen Label, enter the new label in the Screen Label and Field label.

■ To change a Tab Stop for the selected field, enter the field name in the Next Navigation field.

■ To change a codelist associated with the field, double-click in the Code List field and select the name of the codelist associated with the field.

■ To force the case for a field enter U for Upper Case, M for Mixed Case, or L for Lower Case, in the Force Case field.

■ To move a field within a screen, update the coordinates by changing the values for the X-Position, Y-Position, Field Width, and Height (in pixels).

■ To change the Screen Flow, click the Define Windows button and enter the next screen name in the Next Window field.


Configuring the data entry Navigator panelThe data entry Navigator panel is fully configurable. You can create Navigator views that allow you to represent the data summary and navigation features to correspond with your internal data capture form or any other organization.

Table 10–4 Window Modes Table


FORM_NAME N Form Name for the window: Query (Q_Query), Data Entry (E_Entry)

CURRENT_WDW N Current window

DE_MODE N Workflow Task

RECORD_STS N Record status in Workflow Task: N (New), U (Update)

NEXT_WDW Y Next window for screen navigation

CUR_DFLT_CURSOR_LOCTN

Y The default cursor location for the current window (comprised of the block name, a period [.], and field name)

DISABLED_FLAG Y Y (Yes) if window is disabled in this mode

DFLT_INIT_REC Y New, First, Last: The default record for the current window



Each Navigator view is defined as one or more Record Groups. The Record Groups are named according to the controlling entries in the Code List DETREE_VIEW. The syntax of the Record Group entries is strictly defined. The view is defined as a series or Union'd SQL statements. Each SQL statement returns five columns.

Creating the Code List entryFor each discrete view, there must be an entry in the Code List called DETREE_VIEW.

1. Launch the Oracle AERS Global Maintenance subsystem.

2. Select Code Lists tab from the main screen.

The Code List Maintenance screen displays with a list of code lists.

3. Select the code list DETREE_VIEWS from the Navigator panel.

4. Click in the Code field.


■ Code Value Text: The value that displays in the drop-down menu in Data Entry. For example, MedWatch.

■ Lang: en.

■ Display #: Not used.

■ Retired: False

■ Customizable: True

■ User Enterable: True


The new tree name is saved to the database.

Creating Record GroupsThe content of a tree is controlled by a series of SQL statements stored in the RG_ATTRIBUTES table. The name of the Record Groups is based upon the name of the tree view entered in the DETREE_VIEWS Code List (above).

To add the Record Groups for a tree:

1. Launch the Oracle AERS Field Attributes application, if not running.

2. Click the Define Record Groups button one the main screen.

3. Enter the following information:

■ Code Value DETREE_treenameN; where treename is the DETREE_tree name is the name of the tree as identified in the Code value for the DETREE_VIEWS codelist. Each tree must have an entry in the RG_ATTRIBUTES table that exactly matches the name of the Code in the DETREE_VIEWS codelist. If the SQL that displays the tree is longer than 2000 characters (likely) up to 9 additional Record Groups can be defined named DETREE_treename1 through DETREE_treename9. The system concatenates these Record Groups in sequence, then executes them together. This sets an upper limit of 20,000 characters for the full SQL statement.

■ Code List Exectbl Text: The SQL statement for the display view. See next section for syntax details.

■ Refresh Flag: N



■ Lov Name: <null>, not used.


The new tree name is saved to the database.

Creating the SQL statement to display the Navigator viewThe definition and use of the column is as follows:

Column 1: Default Node expansion.

Column 2: The Node Level. Values 0 - 4. Zero (0) is the root level for the tree. More than four levels is impractical.

Column 3: The Node Label. This can be a simple label for a super-node, a simple value for data, or a concatenation of a label and a value. When including values, you may use global forms variables as well as selects for Oracle AERS tables and columns.

Column 4: Icon filename. If you want to include an icon along with the node label, you can specify the filename here. By using the DECODE statement or by creating icons with names corresponding to data values, you can dynamically control the icon that appears in the view. An example of this DECODe is used for the Primary indicator; the naming approach is used for the flag icons. Icons must be 16x16 pixels and in ICN format. The file extension is optional.

Column 5: This is a multipurpose column of three parts with dash (-) separators.

XX-window name-block_name.item_name#display seq

Values:

■ XX - The sort order of the node within the tree. Suggested use A1, A2, ... Z9.

■ window name - if navigation desired.

■ block_name.item_name#display seq - to navigate to a particular record in child.

When a tree contains multiple SQL statements, they should be UNION'd together.

Some examples:

■ Display the Case ID for the active case at the highest root level, expanded, with the Clipboard icon.

select 1,

1,

:global.caseid,

'clipbrd',

Values Description

1 Expand the node

-1 Collapse the node

0 An end node (not expandable

Note: This is sorted as an alpha (character) value so A12 sorts before A2.

Configuration consistency constraints


'00'

from dual

■ Display the string "Subject" at the second node level, expanded, with navigation to the Demographics window, and within the node, concatenate the patient Sex and Age together on a node end.

select 1,

2,

'Subject',

'clipbrd',

'',

'A1-DEMOGRAPHICS_WDW'

from dual

union

select 0,

3,

decode(PT_SEX_CD, 'M', 'Male', 'F', 'Female', 'Unknown')

|| ', ' || PT_AGE_CHR ,

'',

'A2-DEMOGRAPHICS_WDW'

from ae_cases

where case_id = :global.caseid

There are many additional examples that can be learned from the default trees included in the core product.

Configuration consistency constraintsIt is possible to create inconsistent data in the Oracle AERS configuration tables. For example, one check counts the number of entries in each code list for each language to verify the same number have been added. Oracle AERS ships with a SQL script located at the root of the Oracle AERS CD-ROM in a directory called 'sqltools' that checks the configuration tables for many of these consistency violations (FATcheck.SQL).

Potential inconsistencies include:

■ Code list entries not containing a code for each language. This is particularly troublesome if data is entered into the system with codes, which cannot be translated into the RPT language. Results in reports missing sections or cases

■ Inconsistent label entries for screen fields for the same database column across the forms. The inconsistency shows up in reports (which dynamically load the field labels).

Note: The use of A1 and A2 in the Union’d statements; these control the sort order within the full tree.

Configuration consistency constraints


■ Fields appearing in multiple places in multiple forms assigned different lookup lists.

■ A field with a lookup containing an incorrect entry in FIELD_LOV_COLUMN_ MAPPINGS. Results in either runtime errors or incorrect values stored in the data.

■ A RG_ATTRIBUTE table entry missing for a lookup field. Results in a runtime error.

■ A SQL lookup does not return the same number of columns as there are field LOV column mapping entries. The SQL statement RG_ATTRIBUTES table and the FIELD_LOV_COLUMN_MAPPINGS table are all sensitive to the number of columns in the SQL statement.

■ A Workflow Task not contained in the USER_ROLES code list. Results in the inability to grant a user access to that particular Workflow Task.

■ Window and field mode entries are missing for a Workflow Task.

■ The MOD_REASON_LIST does not contain an entry that corresponds to each Workflow Task.

■ The initial cursor location is in a hidden or disabled field.

■ The cursor location in the RAT is in a hidden or disabled field. Results in placing the cursor in field which cannot be modified and asking the user to modify it (if the edit check fails).

■ The 'next cursor' locations are not in a single loop (it should loop back to the first field).

■ Two different fields in a window pointing to the same next field. Results in Shift/Tab action failure.

Managing Users And User Groups 11-1

11 Managing Users And User Groups

This chapter provides instructions for setting up users and user groups, and their security privileges, in the Oracle AERS installation. It includes the following topics:

■ Overview of Oracle AERS user security

■ Setting up Oracle AERS for users

■ Maintaining user groups

■ Maintaining users

■ Local privacy and security

■ Record-level filtering

■ Managing passwords

Overview of Oracle AERS user securityThe Oracle AERS security mechanism enables you to control both the functions users may perform and the cases they can access. You can control security at the Oracle AERS site, user group, and user levels.

■ An Oracle AERS site represents a location of an Oracle AERS server.

■ A user group may represent a department, division, sub-division, or even an external company such as a CRO, corporate partner, or client.

■ A user represents an individual with an Oracle User ID and password with access to Oracle AERS.

To have access to case information, the following must be in place:

1. The user group must have viewing and/or case action permissions for the case.

2. The user must have viewing and/or case action permissions for the case.

This overview introduces Oracle AERS Security objects and provides an introduction to the Types of Oracle AERS security.

Security objectsYou can set security on the level of the Oracle AERS sites, user groups, and users.

User groupsYou assign each user group one or more product codes, and optionally, study ids via product groups. Depending on which product groups are assigned, user groups have access to cases. When you create a user, that user must belong to a user group to access

Overview of Oracle AERS user security


cases. By default, the user may not have a permission that does not belong to his particular user group. For example, if a user group does not have permission to assess cases, users within that group may not be given permission to assess cases. If a user group has a parent user group, the users in the parent user group can always read and update the child's cases, regardless of their own ownership privileges. The parent user group must minimally have the same security permissions as the child.

UsersYou assign individual users one or more product codes and, optionally, study IDs via product groups. For each product group, you may grant users read, create, update, delete, submit, and/or assess permission, in any combination. They also may be restricted from performing certain actions based on their job function.

Users cannot have permissions that are not granted to their user group. For example, if a user group does not have permission to assess cases, a user within that group cannot be granted permission to assess cases.

Types of Oracle AERS securityThe various security features within Oracle AERS interact to control both what functions a user can perform and the case data on which they can perform those functions.

Case ownershipEvery case has an owning user group. This case owning user group defaults to the group that creates the initial case, but you can change the owning user group by modifying a field on the Case Status screen.

You can set user groups to Read Only Mine or Update-Only Mine. When a user attempts to access a particular case, Oracle AERS checks these ownership flags for the user’s user group to determine whether it should allow or deny access to the case. Ownership of a case may extend upward to a parent group of the current user group.

Case permissionsEvery case is associated either with a product code or, for clinical cases, a study. Case permissions security determines users' access and actions. The system defines case permissions by Product Codes and, optionally, studies (Study IDs) or protocol and control who may create, read, update, delete, assess, or submit a case. You can organize product codes and optional study IDs into product groups for easy assignment. Permissions are defined at three levels: Oracle AERS site, User Group, and User.

This level of security permits control of a case in the following areas:

1. Case Creation – Saving a new case.

2. Case Read – Reading/reporting a case.

3. Case Update – Changing any case data.

4. Case Deletion – Deleting a case.

5. Case Assessment – Changing any assessment field.

6. Case Submission – Running a report in submission tracking mode.

Managing Oracle AERS Roles


Oracle RolesOracle AERS uses two database roles to control access to underlying AERS objects. ENUSER is a required role that allows users to manipulate AERS database objects only while connected through the AERS front-end (it is a non-default role that is enabled when a user successfully connects to AERS). ENREAD is an optional role that gives users read access to AERS case data tables from external applications such as SQL*Plus, Oracle Discoverer, SAS, or other ad hoc reporting tools). You must grant this role to users for them gain access to Oracle AERS data from external applications.

Portal Roles/GroupsAERS uses Portal security functions to control access to Content Areas such as the AERS Document Folders and items within those folders. Portal security features are assigned at the Portal User and Portal Group levels for each object type.

Oracle AERS User RolesOracle AERS User Role security provides the ability to turn on or off certain Oracle AERS functions for a user based upon the Oracle AERS roles assigned to the user in the Oracle AERS database. The roles control the following functions:

1. Access to menus and other AERS functions.

2. Running reports and letter templates.

3. Workflow Task access.

4. Supervisory Functions – The Supervisor role enables access to restricted items belonging to other users (i.e., queries and save Case Lists), and allows the supervisor to add or delete Oracle AERS users and update user privileges.

5. Discrepancy Management – This role enables a user to close discrepancies found during data validation.

Setting up Oracle AERS for usersOracle AERS has a logical flow of setting up Oracle AERS sites, product codes, studies, product groups, user groups, and users. You should follow this sequence. You need to:

1. Define Oracle AERS sites.

2. Define Product Codes.

3. Define Studies (optional).

4. Define Product Groups.

5. Grant Oracle AERS Site Permissions.

6. Manage Oracle AERS Roles.

7. Define User Groups and ownership security.

8. Grant User Group Permissions.

9. Define Users and their roles.

10. Grant User Permissions.

Managing Oracle AERS RolesOracle AERS manages all application, database and portal roles from within the AERS Administrator Console. Oracle AERS maintains in the Role Attributes table all of the

Maintaining user groups


roles it uses. Whenever you add a new report security role, workflow step, portal group, or other role-based control, you must insert the new role into the Role Attributes table.

In Oracle AERS 4.5.2, roles have attributes that pertain to their basic function. This feature allows a single role to serve many functions. For example, an application role can continue to control access to a function, but you can also tag it to confer Supervisor responsibilities.

To add or update a role:

1. Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.

2. Select the Role Attributes tab from the Administrator Console.

The Role Attributes screen displays.

3. Add a new row, and fill in the following fields.

■ Role: The name of the new role, which must be unique throughout the AERS site.

■ Supervisor: This checkbox determines whether the role has supervisor privileges. You can add supervisor privileges to any role in Oracle AERS.

■ Database Role: A database level role. In AERS 4.5.2 there are only two database roles: The required ENUSER role and the optional ENREAD role.

■ Portal Group: Portal groups function as roles within the Portal environment. When you grant a user this type of role, Oracle AERS adds the user to the Portal group, conferring the privileges of that group to the user.

■ Application Role: If the role is a workflow step, report role, or letter role, then check this box. All of the roles ending in "ENRL" are reserved roles corresponding to the menu security.

4. Click the Save button, or press the F10 key, to save the role.

Oracle AERS saves the role to the database.

Maintaining user groupsA user group is a group of individuals you collectively assign one or more specific product groups. A user must belong to a user group to have access to cases, and may belong to only one user group. User groups in Oracle AERS correspond to organizational divisions (as opposed to functional similarities).

This section describes the following user group maintenance tasks:

■ Understanding user group permissions

Note: This feature differs from previous releases of AERS, in which you could only confer supervisor privileges by granting the reserved role SUPERVISOR.

Note: You perform user group maintenance in the local Oracle AERS application.



■ Adding permissions to a user group

■ Adding user groups

■ Updating user groups

■ Deleting user groups

Understanding user group permissionsYou can grant create, update, delete, assess, or submit privileges to user groups and users for one or more product groups. Specify the user group's permissions by clicking the Create, Update, Delete, Assess, or Submit checkboxes. A blank (default) checkbox is False, meaning no permission has been assigned. For example, a blank Submit checkbox indicates no user in the user group has permission to submit cases. Oracle AERS automatically grants read privileges when a product group is entered in the Product Group ID field. Users must be granted the Update permission before they may receive the Assess, Delete, or Submit permissions.

For example, you could give a user group access to create cases for a particular study, but deny them update privileges. You could allow another user group to create and update cases for a study, as well as the privilege to update cases created by other user groups.

Table 11–1 defines the access permissions.

Adding permissions to a user groupTo add permissions to a user group:

1. Position the cursor in the Product Group field in the Permissions area.

2. Enter the product group name to be assigned, and check the appropriate permissions.

Adding user groupsTo add a user group:


2. Select the User Profile tab from the Administrator Console.

Table 11–1 Access Permissions

Permission Definition

Create May create case

Read May read a case

Update May change case non-assessment fields (only)

Delete May delete case

Assess May change case assessment fields (only)

Submit May run a report in submission mode

Note: Oracle AERS implicitly grants the Read permission to the product group. If you only want to grant read permission, enter the product group and leave the checkboxes unchecked.



The User Maintenance screen displays.

3. If the User Group Profile is empty, position the cursor in the User Group field or add a row.

4. Enter the appropriate fields in the top portion of the screen.

■ Read Only Mine/Update Only Mine: user groups have two specific ownership attributes, Read Only Mine and Update Only Mine, which control whether its users can read or update cases entered by users from a different user group. You can give a user group permission to read and/or update another user group's cases. Checking the appropriate checkbox in the user group's Maintenance screen restricts a user group from reading or updating cases other than their own. A blank (default) checkbox is False, meaning the user group may read or update another user group's cases.

■ Parent User Group: When a user creates a case, that user’s user group owns the case. A user group may have a parent; the parent user group can read and update all case data of the child. Parent user groups are typically utilized when user groups are created for contract organizations. If a contract organization is assigned a parent user group, users within the parent user group can read and update any cases that the child owns, independent of the parent's Read Only Mine/Update Only Mine privileges.

■ Organization, Division, Sub-division are all optional.

5. Click the Save button, or press the F10 key, to save the user group.

Oracle AERS saves the user group to the database.

Updating user groupsTo update a user group:




3. Select the user group you want to update from the Navigator panel.

4. Enter the appropriate changes.

5. Click the Save button, or press the F10 key, to save your changes.

Oracle AERS saves the user group with updates.

Deleting user groupsYou cannot delete a user group if users currently belong to it. You must first reassign users to another user group.

Deleting a user group can result in a situation where no user within Oracle AERS has access to specific cases. For example, if three cases are owned by the user group Artemis, and you delete Artemis and no other user group has access to the same Product Code and Study IDs, no system users can access those cases.

There are two solutions to this situation:

■ You can create a "Super User," a user with All Product Groups and all permissions, who belongs to a user group with no restrictions ("Read Only Mine" and "Update Only Mine" are false, and all permissions are "True").

Maintaining users


■ You can query for all cases belonging to the user group that you are going to delete, change the owning user group to another user group, and then delete the user group. You would need to ensure the new owning user group was granted the proper permissions and product groups.

To delete a user group:

1. Open the Administrator Console by clicking the subsystem button or selecting Maintenance=>Administrator Console.



3. Select the User Group you want to delete from the Navigator panel.

4. Click the Delete Record button.

5. Click the Save button, or press F10, to save the deletion.

Oracle AERS does not prompt you, and deletes the user group from the database.

Maintaining usersAs a restricted, proprietary computer application, Oracle AERS limits access to authorized users. Each user must have a valid, unique Oracle User ID and Oracle password to log on to Oracle AERS. Oracle AERS provides security features beyond those provided by Oracle, so you must also define the user to Oracle AERS. You, an Oracle DBA, or other authorized individual create users using both the Oracle database and Oracle AERS system.

You perform all user maintenance tasks, including creation of new users, from within the Oracle AERS Administrator Console. These tasks include:

■ Creating AERS users on page 11-7

■ Assigning Oracle passwords on page 11-8

■ Assigning roles on page 11-8

■ Updating user attributes and permissions on page 11-12

Creating AERS usersAERS users have three components: an Oracle database account, a Portal User, and an Application User. The system manages and synchronizes all of these components centrally in the Administrator Console. Only users with the DMNT_USER_SEC_MOD_ENRL can create users.

To create a new user, you may either create a new, fully privileged user, or copy an existing user:

1. Open the Administrator Console by clicking the subsystem button or selecting Maintenance=>Administrator Console.



3. Select the Create New User command from the Actions Menu.

The Create New User dialog box appears.

4. Enter the new user’s User Group and User ID.

Maintaining users


The User ID must conform to Oracle Username restrictions (30 characters). The User ID corresponds to the Oracle database user; AERS also captures User Name as an attribute of the user.

5. To create a new, fully privileged user, check the Fully Privileged box; otherwise, enter the User Group and User ID that you want to copy.

6. Click Create User.

Oracle AERS confirms the action, then creates the user.

Assigning Oracle passwordsWhen you create a new user, the system automatically assigns the user an expired password: the user’s username concatenated with ’123.’ Oracle passwords may be a minimum of one character and a maximum of 30 characters. Oracle accepts alphanumeric combinations, and passwords are not case-sensitive. You can choose to add additional password complexity rules using the Oracle Portal SSO password rules.

Oracle passwords are valid for a limited number of days. This number is set in the Oracle AERS Controls table during system implementation, but you can change it at a later time. Three days before expiration, the system automatically warns users when they log on to Oracle AERS, reminding them to change their current password. Users can change their password after expiration by attempting to log on to Oracle AERS (the Change Password dialog box pops up automatically, and users must change the password before proceeding).

If a user forgets his or her password, you can reset it by following the procedure in "Resetting a user’s password".

Assigning rolesUsers gain access to Oracle AERS menus through the assignment of Oracle Menu roles. You must assign AERS roles to users based on job function. There are four types of user role in an Oracle AERS environment:

■ Baseline Oracle Roles on page 11-8

■ Optional AERS Roles on page 11-9

■ Other AERS Application Roles on page 11-10

■ Portal Groups (Roles) on page 11-11

The section "Assigning roles to a user" on page 11-11 describes how to assign any of these roles to a user, or remove these roles from a user.

Baseline Oracle RolesEvery Oracle AERS user must have the following three Baseline Oracle Roles. Except for ENUSER, you can set these Baseline Oracle Roles as the user’s default.

Table 11–2 Baseline Oracle Roles

Menu Role Visible Menus/Permissions

ENUSER Non-default password-protected role: access to Oracle AERS tables only when logged into Oracle AERS (cannot access Oracle AERS tables via SQL*Plus).

CONNECT Oracle user role, which users require to connect to Oracle.

Maintaining users


Optional AERS RolesTable 11–3 lists the optional Oracle Menu Roles you can assign, according to job definition.

COMMON_MENU_ENRL

(Oracle menu role)

Gives the minimum menu bar: File=>Print Screen, Exit, Window (all), Help (all). Data Mnt=>Change Password (all): All users must have this.

Table 11–3 Oracle AERS Roles


BR_EXTAPP1_ENRL Toolbar item that invokes external application (default is Brio)

BR_UPDATECASESTS_ENRL Case Browse menu: File=>Case Status Mass Updates. Must have to update case status

BR_UPDATESUBM_ENRL Case Browse menu: File=>Update Submission Dates. Must have to update submission mail dates.

DE_CREATECASE_ENRL File=>New Case; Copy Case. Must have to create a case.

DE_DELETECASE_ENRL Case Actions=>Delete. Must have to delete a case.

DE_DRUGLABEL_ENRL Case Actions=>Drug Labeling. Must have to perform drug labeling in Assess mode.

DE_GENLETTER_ENRL Case Actions=>Generate Letter

DE_GENNARRATIVE_ENRL Case Actions=>Generate Narrative. Must have to generate case narratives.

DE_MODIFYCASE_ENRL File=>Open from Data Entry and Cases=>Update Case from Case Browse menu.

DE_ROLLUP_ENRL Case Actions=>Rollup Derivation. Must have to perform rollup function.

DE_SUBMWIZARD_ENRL Case Actions=>Submission Wizard

DE_UNDELETECASE_ENRL Case Actions=>Undelete. Must have to undelete a case.

DE_VIEWCASE_ENRL Cases=>Browse Case, View Case.

DMNT_CONTROLS_ENRL Maintenance=>Administrator Console=>System Parameters tab

DMNT_OPTIONS_ENRL Maintenance=>Options – Gives access to Option menu.

DMNT_REPORTS_ENRL Maintenance=>Admin Console=>Reports Maintenance tab

DMNT_USERSEC_ENRL Admin Console=>User Profile tab

DMNT_USERSEC_MOD_ENRL Admin Console=>User Profile tab, with the ability to update user attributes.

DMNT_ADDRESSBOOK_ENRL Allows users to create and edit address book entries

DMNT_LETTERS_ENRL Maintenance=>Admin Console=>Letters tab

DMNT_RULEATTRIBUTES_ENRL

Maintenance=>Admin Console=>Rule Attributes tab

Table 11–2 (Cont.) Baseline Oracle Roles


Maintaining users


You can assign the following role to users that require ad hoc query access through SQL*Plus or other external applications to the local Oracle AERS database. These roles grant read-only access to Oracle AERS tables: the ENREAD role for ad hoc access to Oracle AERS. Because the ENREAD role does not enforce Oracle AERS READ security restrictions assigned to users and user groups, you should grant this role only to users who already have READ permission to the 'ALL' Product Group.

Other AERS Application RolesOracle AERS user roles allow you to define specific roles for Oracle AERS users based on job function. Oracle AERS user roles perform three functions:

■ Control access to reports and letters.

■ Control whether users can select a particular workflow task. The workflow task and the user role must match.

■ Control user records, security, and objects.

Your organization has the option of creating several Oracle AERS user roles during an Oracle AERS installation to delegate user access to various Oracle AERS activities. For example, if you configure two workflow tasks, DE (Data Entry) and ASSESS (Assessment), you can control which users can enter the ASSESS Workflow Task by selectively assigning the ASSESS Oracle AERS user role to those users.

Oracle AERS contains several core Oracle AERS user roles. You can configure any of these roles except for SUPERVISOR and CLOSE_DISCREPANCIES roles, which are hard-coded.

LMNT_CASEMNT_ENRL Case List management

LMNT_COUNTRYMNT_ ENRL Country List management

LMNT_DRUGMNT_ENRL Product List management

LMNT_PATIENTMNT_ENRL Patient List management

LMNT_STUDYMNT_ENRL Study List management

MODIFY_LIST_ENRL May add, delete, or save changes to each type of List. Must have the corresponding List role, e.g. lmnt_casemnt_enrl, lmnt_countrymnt_enrl.

QRY_RUN_ENRL Cases=>Query Case

RPT_RUN_ENRL Batch=>Reports=>Run/Monitor Reports

Menu Role Permissions

ENREAD Grants read-only access to Oracle AERS tables for ad hoc query capability (see Ad Hoc section below).

Note: The Controls Table contains sensitive information such as Portal IF User passwords; therefore, when setting up an Oracle AERS User with ad hoc query access at an Oracle AERS site, you should give the user a private synonym named CONTROLS, which points to the CONTROLS_READONLY view owned by the Oracle AERS schema owner.

Table 11–3 (Cont.) Oracle AERS Roles

Menu Role Visible Menus/Permissions (Cont.)

Maintaining users


Portal Groups (Roles)Oracle AERS also uses Oracle Portal roles to control access to content areas and Portal administration features. You can manage these roles within AERS, but they control features within the Portal environment:

Assigning roles to a userThe process of assigning roles to and removing roles from a user are similar. To assign a role to, or remove a role from, a user:




3. Select the user you want to update from the Navigator panel.

4. Select Manage User Roles from the Actions menu.

The Manage Roles dialog box appears.

5. Select the roles to assign from the Available Roles panel and press the Add (>) button.

6. Select the roles to unassign from the Assigned Roles panel and press the Remove (<) button.

7. When you are finished, click the Done button.

AERS Role/Type Permissions

SUPERVISOR/Core Non-default password-protected role: access to Oracle AERS tables only when logged into Oracle AERS (cannot access Oracle AERS tables via SQL*Plus).

CLOSE DISCREPANCIES/Core

AERS role that allows a user to close a discrepancy when it is initially raised by an edit check.

ADMIN/Workflow A standard workflow step that provides access to all screens and fields within the Case Data Entry subsystem.

DE_GENLETTER_ENRL/Letter

The default Letter template role that is assigned to all example letter templates.

REGULATORY_RPT/Report

An example report role allowing users to run any report that has this role assigned.

REPORT_NOT_USED/Report

A reserved report role that is used to hide reports across all users.

Portal Group Permissions

AERS_USERS The default group for all AERS users. Each AERS user MUST be a member of the this Portal Group.

AERS_DOCUMENT_MANAGERS

Allows the user to add folders and items to the public folders in the AERS Folders content area.

AERS_ADMINISTRATORS

Gives the AERS user permissions to manage Portal security and other portal features, but not the broad administration privileges that the Portal User (PORTAL30) has.

Maintaining users


Updating user attributes and permissionsTo update a Oracle AERS user profile:




3. Select the user you want to manage.

4. Key in the appropriate fields in the top portion of the screen.

■ User Options are default values for the User's Data Entry options. You can set all options for the user in the Users Maintenance screen when creating their User ID. Depending on their security permissions, the user may change these options during their Oracle AERS session via the Options screen (except where noted).

Table 11–4 User Attributes and Permissions

Option Description

(DE Functions) Mode Specific, configurable mode for Data Entry: depending on Workflow Task, the user may or may not have access to specific Data Entry screens. The following Data Entry behaviors may be affected by the particular Workflow Task: tab order, next screen sequence, screen enabled, field hidden and enterable, default edit reason, and edit rules. If the user switches Workflow Tasks while Data Entry subsystem is active, the field attributes change and the first screen of the new mode displays.

View Only View-only access to cases: no editing, adding, or deleting case data is allowed. This option is display-only on the Options screen.

Prompt for Change Reason

Requires the user to enter a reason for editing a case. Oracle AERS supports a default audit reason for each Workflow Task. The user may, however, write their own text in addition to, or instead of, the default reason. If not activated, the default change reason for the specific Workflow Task is recorded in the audit trail.

(Edit Checks) Heads Up Soft error rule designation: if selected, Soft rules are run interactively. If the rule is violated and there is no entry for this error in the discrepancy log, the User is given the choice of fixing the error. This option is display-only on the Options screen.

(Edit Checks) Heads Down

Soft error rule designation: no Soft rules are run until the batch edit validation is run. User receives no message if a Soft error is entered. This option is display-only on the Options screen.

(Display) Language Each AERS user has a default language setting. This value can be set to any language, and if there are local language translations corresponding to the user’s language, the user interface (field labels, value decodes, menus, error messages, etc.) is displayed in that language.

(Query/Browse) Pause Interval

Number of cases returned by a query before pausing. At the pause, the user has three choices: (Stop Query) returns user to the Browse screen with all cases fetched to that point in the active Case List, (Run) returns the next interval’s number of cases, or (Run to End) returns all remaining cases with no further interruptions.

Maintaining users


5. Click the Save button, or press F10, to save changes.

The system saves the user to the database.

User permissionsYou can grant create, update, delete, assess, or submit privileges to user groups and users for one or more Product Group. Specify a user's permissions by clicking the Create, Update, Delete, Assess, or Submit checkboxes If a checkbox is blank, the user does not have that privilege. For example, a blank Submit checkbox indicates no user in the user group has permission to submit cases. Oracle AERS automatically grants Read privileges when you enter a Product Group in the Product Group ID field. You must grant users the Update permission before they can receive the Assess, Delete, or Submit permissions.

User Permissions, User Group Permissions, and Site Permissions interact to control case data access. A user must have permission at each level in order to perform the action. For example, to read a case, the Site must have the case (i.e. Site Permissions), the user's user group must have Read permission for the case, and finally, the user must have read permission for the case.

Table 11–5 defines the access permissions for users.

To add permissions to a user:

1. Position the cursor in the Product Group field in the Permissions area.

2. Enter the Product Group name to be assigned, and check the appropriate permissions.

Save Lists Saves all the variables used to create a Case List. All selection criteria, query parameters, and Lists used to create a Query are saved so the user has a record of the criteria used to create the Case List. This option is display-only on the Options screen.

Auto Refresh Cases are automatically unpicked from the Case Browse screen following assessment of a case.

Default Printer Default server printer for all reports.

Table 11–5 Access Permissions for Users

Permission Definition

Create May create case

Read May read a case

Update May change case non-assessment fields (only)

Delete May delete case

Assess May change case assessment fields (only)

Submit May run a report in submission mode

Note: Oracle AERS implicitly grants the Read permission to the Product Group. If you only want to grant read permission, enter the Product Group and leave the checkboxes unchecked.

Table 11–4 (Cont.) User Attributes and Permissions

Option Description

Local privacy and security


Local privacy and securityOracle AERS uses a combination of field-level settings and User Group permissions to control viewing and updating of “local” data. The local security and privacy features are designed to balance the needs to data confidentiality and ownership with the benefits of a single global database repository.

With this feature, you can configure a field to be “private” or “secure” to the Owning User Group. A “private” field is one that can only be viewed and updated by a member of the User Group that owns the case. A “secure” field is one that can only be updated by a member of the User Group that owns the case.

For example, France has patient privacy laws that prohibit viewing patient details outside of France. With this feature, you can configure the patient details to be “private” to the French User Groups. A user in the French User Group is able to see the patient details for any case created by a user in the French User Group – all other users see asterisks (*) in the field in place of data and the field itself is non-enterable (grey).

Configuration Components

User Group membershipThe basis of local privacy and security is the Case Ownership. By default, a case is owned by the User Group that created the case, though ownership can be transferred by updating the Case Owning User Group field on the Case Details screen. If a field is marked as private or secure, a user must either be in the User Group that owns the case, or in a User Group that shares the same Parent User Group in order to access the private or secure data. In keeping with the above example, if you have two User Groups in France with the same Parent User Group users from either group is able to see the private data for cases owned by either User Group. This feature is another driver in the user and User Group configuration within AERS: if your implementation encompasses global workgroups and further, if local User Groups are processing data, you should establish your User Groups to reflect the geography of the local privacy rules.

Security scope codelist(s)The scope of the privacy must be defined by a code list of User Group IDs. The codelist should encompass any User Group that defines a given field as Private or Secure. For example, if both France and German have local privacy laws governing the viewing of particular fields, your codelist should include all of the French and German User Groups. The codelists are then assigned to the individual fields as appropriate.

Field-level configurationThe final aspect of the configuration is the field-level definition of privacy and security. Each field has two attributes that define the scope of local access: Private in User Group and Secure to User Group. To identify a field as a “private” field, you simply enter the name of the codelist that encompasses the full scope of the privacy restrictions on that field. Similarly, if a field is considered “local” data, you can assign the codelist that encompasses the full scope of User Groups that consider the data to be private.

Local privacy and security


Example 1: Local Privacy configuration for patient name and addressIn this scenario, AERS is deployed globally and users in France and Germany would like to enter patient details into the case, but these details must remain “private” so that users outside their countries cannot view the patient details.

Configuration steps:1. Set-up two User Groups, one for each of the local offices in France and Germany.

Name the User GroupsPV_FRANCE and PV_GERMANY respectively. Add users to the User Groups as needed.

2. Create a codelist that defines the scope of the privacy. In this scenario, both France and Germany consider the patient details to be private, and as such, the codelist needs to contain both PV_FRANCE and PV_GERMANY. For this example, name the codelist PATIENT_PRIVACY_GROUPS.

3. Assign the codelist to each of the fields that should be considered private. In the main Workflow configuration screen, enter the codelist name, PATIENT_PRIVACY_GROUPS, into the "Private in User Group List" field for each private item.

Once this is configured, any case created by the PV_FRANCE group is treated as “private” to the user’s within that group. When the user who created the case, or any other member of the PV_FRANCE User Group opens the case, they are able to see and update the patient details. However, a user in any other User Group, including PV_GERMANY, only sees asterisks (*) in the private fields. Similarly, any case created by a user in PV_GERMANY is private to the members of that User Group.

Example 2: Local Security configuration for assessment dataIn this scenario, AERS is deployed globally and users in Germany would like to treat the Risk Benefit narrative (AE Treatment) they enter into a local case as “local” data that only they can update.

Configuration steps:1. Set up a User Group for the German users. For this example, name the user group

PV_GERMANY. Add users to the User Group as needed.

2. Create a codelist that defines the scope of the locally secure data. In this scenario, the users in Germany consider the Risk Benefit analysis to be “local” data for any German case but no other User Groups feel any proprietary ownership over this data. As such, the codelist need only contain one User Group ID, PV_GERMANY. Let’s call the codelist LOCAL_GERMAN_GROUPS.

3. Assign the codelist to the AE Treatment field. In the main Workflow configuration screen, enter the codelist name, LOCAL_GERMAN_GROUPS, into the "Secure in User Group List" field for the AE Treatment item.

Once this is configured, any case created by the PV_GERMANY group is treated as “secure” to the group and the secure field is only updatable by users in the PV_GERMANY User Group.

Record-level filtering


Configuration Procedure

Creating the CodelistFor every local User Group that considers a field or set of fields as “private” or “secure”, you must create a codelist that contains the complete list. If there are different combinations of privacy or security rules, then a codelist needs to be created for each distinct set of privacy restrictions. For example, if France and Germany both consider Patient details private, but only Germany considers Physician Details private, you need to create two codelists: One with both the French and German User Groups lists, and another with only the German User Groups listed.

1. Login to the AERS Global Maintenance application and navigate to the Codelists tab.

2. Create a new code list:

■ Enter the Codelist Name and Description.

■ Set the Customization Type to “C” for customizable.

3. Enter codelist values:

■ Enter the User Group name as the Code.

■ Enter the Language Code “en”.

■ Set the User Enterable flag to Y.

■ The Retired Flag should be N.

■ The values of the other attributes are optional.

4. Save the Codelist.

Configuring the Security CodelistTo configure each private or local field with the appropriate security codelist, you use the Field Attributes screen in the Oracle AERS Workflow Configuration application. Any given field can only have a single Privacy List and a single Locally Secure list assigned to it. As such, it is critical that the analysis is done with this in mind so the correct lists can be created. Enter the codelist name into the appropriate Field Attribute.

1. Login to the AERS Workflow Configuration application.

2. Retrieve the field(s) to be updated by selecting F7 (Enter Query), entering the selection criteria (e.g. Window Name), and selecting F8 (Execute Query).

3. Update the "Private in User Group List" and "Secure to User Group List" attributes with the codelists created in "Creating the Codelist".

4. Repeat for each field.


Record-level filteringOracle AERS includes the ability to “filter” records in Reportability/Submission Tracking and Product Investigation blocks. This feature allows you to configure AERS so that some users only see certain reportability/submission tracking records to product quality investigations. This feature uses a combination of country lists and codelists for authorized lists, User roles, and data entry mode attributes.



With this feature, you can configure a workflow step to filter either Reportability/Submission Tracking Records and/or Investigations. The workflow steps can then be assigned to users who should have restricted access to these records. These restrictions can be imposed either for convenience and clarity (such as in a global deployment where local users need only see records pertinent to their country responsibilities) or they can be imposed for security or privacy reasons.

For example, a local affiliate, say in France, can be granted reporting responsibility for France and Belgium. Using this feature, a “Local Reporting” workflow step can be created that filters Reportability and Submission Tracking Records. The local affiliate users are then assigned a User Role that corresponds to a country list consisting of FRA (France) and BEL (Belgium). With this configuration, when the local affiliate user opens a case in the Local Reporting workflow task, they only see Reportability and Submission Tracking records for the countries in its authorized list (FRA, BEL).

A similar example can be described for Product Complaint users: A workflow task can be created that filters Investigation Records. Product Complaint users with limited access rights can be assigned a codelist consisting of Assignments. When this user opens a case in the workflow task, they only see investigation records that are assigned to an entity in the codelist.

Configuration componentsThere are three components to the record-level filtering configuration:

Authorization ListsThese lists define the scope of the filtering. Reportability/Submission History filtering is based on a Country List. The Country List(s) consists of the unique list of countries that are limited. Product Quality Investigations filtering is based on a Codelist. The Codelist is an arbitrary list of names that are used in the Assigned To field in the Investigations tab. These lists are created using the standard Country List and Codelist maintenance forms. Both the Country Lists and Codelists are then created as Roles. There are new Role Attributes to define these as Country List or Investigation Lists.

Workflow TasksAny workflow task can be configured to filter Reportability/Submission History and/or Investigations. You simply set the Workflow Task attribute to Y to enable filtering. Any user opening a case with the workflow task has the corresponding records filtered to those countries in their list(s). Note: if a user with no authorization lists assigned opens a case in a filtering workflow task, they see no records in the filtered blocks.

Example 1: Reportability/Submission History filtering for local affiliateIn this scenario, AERS is deployed globally and users in the French pharmacovigilance affiliate office are responsible for submitting reports to the French and Belgium regulatory authorities whereas users in the corporate headquarters are responsible for managing all submissions worldwide. For this type of process, a special workflow needs to be created that filters the Reportability and Submissions History. An authorization Country List is created with France and Belgium then assigned to the local affiliate users.

Configuration steps:1. Create a new workflow step called LOCAL-REPORTING. Set the Filter

Submissions flag to ’Y’ for the new Workflow task.



2. Create a Country List called LOCAL_FRENCH_REPORTING that has two countries FRA and BEL.

3. Create a Role with the same name as the Country List (LOCAL_FRENCH_REPORTING). Set the Country List Role Attribute to ’Y’.

4. Assign the LOCAL_FRENCH_REPORTING Role to the Local Affiliate user(s).

5. Assign the LOCAL-REPORTING Workflow task to the Local Affiliate user(s).

Example 2: Investigation filtering for Product Complaint investigation usersIn this scenario, AERS is being used for managing product quality complaint management. Some of the users assigned to perform the quality investigations should be limited to only managing those investigations assigned to them or their sub-contractors. In this process, a special Complaint Investigation workflow task is created that filters investigations based upon who they are assigned to. Assignment lists are creased as codelists and assigned to those users with limited investigation responsibilities.

Configuration steps:1. Create a new workflow step called COMPLAINT-INVESTIGATION. Set the Filter

Investigations flag to 'Y' for the new Workflow task.

2. Create a Codelist called LOCAL_INVESTIGATIONS, that has a limited set of codes. Each code corresponding to one of the values that can be entered into the "Assigned To" field in the Investigation block. Often this is a user group, but it can be any arbitrary assignment name (like the name of a sub-contractor company) even if that entity is not a user or user group within AERS.

3. Create a Role with the same name as the codelist (LOCAL_INVESTIGATIONS). Set the Assignment List Role Attribute to 'Y'.

4. Assign the LOCAL_INVESTIGATIONS Role to the Local Affiliate user(s).

5. Assign the COMPLAINT-INVESTIGATION Workflow task to the Local Affiliate user(s).

Configuration Procedure

Filtering RecordsTo filter records, create a new workflow step or edit an existing workflow step. The Filter Reportability/Submission History and the Filter Investigations are independent attributes of the workflow task, so it is possible to have a workflow task that filters both. Practically however, you most likely use only one of these attributes with any

Note: In a complete configuration of this feature, you create specific Inboxes for the local affiliates and likely assign the LOCAL-REPORTING workflow as the default (and perhaps only) workflow task.

Note: In a complete configuration of this feature, you create specific Inboxes for the local investigation teams and likely assign the COMPLAINT-INVESTIGATION workflow as the default (and perhaps only) workflow task.



given filtering workflow task. Aside from the filtering aspect, these filtering workflow tasks behave just like all other workflow tasks.

1. Login to the AERS Workflow Configuration application.

2. Click the Workflow Tasks button.

The Workflow Tasks window displays.

3. Retrieve existing workflow tasks by selecting F8 (Execute Query).

4. If desired, create a new Workflow Task by clicking the New Task button and completing the dialog details.

5. To add filtering the workflow step, update the filtering attributes:

■ To filter Reportability/Submissions History:

– Set the Filter Submission Flag = Y on the Workflow Tasks window in AERS Workflow Configuration.

■ To filter Investigations:

– Set the Filter Investigations Flag = Y on the Workflow Tasks window in AERS Workflow Configuration.

Creating an Authorization ListThe authorization list for Reportability/Submission History is managed as a Country List. For Investigations, it is a Codelist.

To create an authorization list to filter Reportability/Submissions History, create a Country List with the list of countries equal to the list of countries/agencies that is used as filter criteria. You need to create a separate Country List for each distinct combination of countries/agencies.

1. Login to Oracle AERS.

2. From the Case Browse screen, select File New… Country List.

The New Country List dialog box appears.

3. Enter the Country List Name and Description, select a destination folder, and click OK.

The Country List maintenance screen appears.

4. Enter the list of countries.

5. Save your list.

To create an authorization list to filter Investigations, create a Codelist with the list of values that is used as assignments in the Investigations block. You need to create a separate Codelist for each distinct combination of countries/agencies.

1. Login to the AERS Global Maintenance application and navigate to the Codelists tab.

2. Create a new code list.

■ Enter the Codelist Name and Description.

■ Set the Customization Type to “C” for customizable.

3. Enter codelist values.

■ Enter the names of the Assigned To values as the Code.

■ Enter the Language Code “en”.



■ Set the User Enterable flag to ’Y’.

■ The Retired Flag should be ’N’.

■ The values of the other attributes are optional.

4. Save the Codelist.

Creating RolesYou create a Role with the same name as the authorization list from the Roles tab of the Administrator Console in Oracle AERS.

1. Login to Oracle AERS.

2. From the Administrator Console, select the Roles tab.

3. Add a new Role record with the same name as the authorization list.

4. Set the Role Attribute:

■ For a Reportability/Submissions History authorization list:

– Set the Country List Flag to ’Y’ for the role.

■ For an Investigations authorization list:

– Set the Assignment Flag to 'Y' for the role.

5. Save your Role(s).

Assigning RolesOnce created, these roles are managed and assigned just like all other User Roles.

1. From the Administrator Console, select the Users tab.

2. Select the user that you want to have the filtering.

3. Select the Manage Roles form the Actions menu.

The User Role Assignment dialog box appears.

4. Assign the role(s).

5. Click OK.

Assigning Filtering Workflow TaskAssigning the filtering Workflow task to the user(s) allow the users with restricted access to manage the case while being securely limited to those records that they are authorized to access.

1. From the Administrator Console, select the Users tab.

2. Optionally, set the Default Workflow Task equal to the Workflow Task created in Step 1.

3. Select the Manage Roles form the Actions menu.

The User Role Assignment dialog box appears.

4. Assign the Workflow Task(s) to the user.

5. Click OK.

Managing passwords


Managing passwordsOracle AERS supports all of the Oracle password security features (such as minimum length, expiration, and reuse). Oracle AERS also includes specific features to control password expiration as well as password changing.

When you create a new user in Oracle, you must also create a password for that user. If the user wants a different password, he must change it manually within Oracle AERS using the Change Password feature.

Configuring passwordsYou set the number of days a password is valid in the Controls table. In addition, you must synchronize the password expiration policy for Oracle Portal.

To change the password expiration timeframe:


2. Select the System Parameters tab from the Administrator Console.

3. Update the control DAYS_PASSWORD_VALID to the number of days before a password changes. The system warns users for 3 days prior to expiration. If the password does expire, Oracle AERS forces users to change their password prior to completing the login process.

To change the Oracle Password security functions:

1. Login to the AERS Home Page as the Portal Administrator and navigate to the Portal Homepage (HOMEPAGE).

2. Select the Edit Login Server Configuration from the Administer tab page.

The Edit Login Server page appears.

3. Update Password Policy rules as desired. Make sure to synchronize the expiration timeframe here and in Oracle AERS Controls table.

4. Click OK. Oracle AERS applies the changes.

5. Close the window.

Unlocking Single Sign-On (SSO)Portal security limits the amount of login attempts a user can make by locking out the user after a predetermined amount of attempts. See "Configuring passwords" for more information. If a user is locked out, you can unlock SSO in the Administrator Console.

To unlock SSO:

1. Navigate to the Administrator Console.


3. From the main menu, select Actions => Unlock SSO.

The Confirm dialog box displays asking "Are you sure you want to unlock the SSO account for <username>?"

4. Click OK

The Success dialog box displays informing you that the SSO account is unlocked for <username>.

5. Click OK.

Managing passwords


The password is reset to the default password <username123>. The next time the user logs into Oracle AERS:

■ the user is prompted to change his password in External Applications.

■ the user is notified that the password has expired, and is permitted to enter a new password.

Configuring application-level timeoutOracle AERS includes a timeout feature, which ends a user’s session after a pre-determined length of inactivity. The inactivity time is established in the Controls table.

To set the inactivity time:


2. Click the System Parameters tab.

3. Under Control ID, scroll down to INACTIVITY_TIMEOUT. This value determines the amount of time before the application closes.

■ Under Control Value, enter the time in seconds.

4. Under Control ID, scroll down to WARNING_TIMEOUT. This value determines the amount of time that a user is inactive before displaying the Timeout screen.

■ Under Control Value, enter the time in seconds.

5. Close the Administrator Console.

Resetting a user’s password

Resetting a password using the Administrator ConsoleUsers with administrator privileges can reset another user’s password from within the Administrator Console.

To reset a user’s password using the Administrator Console:



3. From the main menu, select Actions => Reset User Password.

The Confirm dialog box displays asking "Are you sure you want to reset password for <username>?"

4. Click OK

The Success dialog box displays informing you that the password is reset.

The next time the user logs into Oracle AERS he is prompted to change the password.

The password is now reset in Oracle AERS and in Oracle Portal, however you must synchronize the External Applications password with the changed password.

Note: The default password is <username123>. See "Assigning Oracle passwords"for more information.

Managing passwords


1. In the External Applications section of the Oracle AERS Home Page, click Customize.

The Edit External Applications Portlet Settings screen displays.

2. Click the Changed Stored Password button (pencil icon) next to the link to AERS 4.5.2.

The External Application Login Information screen displays.

3. Enter your new password in the Password field.

4. Click OK.

You return to the Edit External Applications Portlet Settings screen. Repeat these steps if you are a Global Maintenance user.

5. Click OK.

You return to the Oracle AERS Home Page.

Resetting a password using SQL*PlusIf a user forgets his password, you can reassign it by using the Change Password function in the AERSWW_PORTALIF database package. Changing the password with this function ensures that the password is synchronized with Portal.

To reassign a user’s password:

1. Log on to SQL*Plus as the AERS schema owner (AERS1).

2. To run a function within a portal package, you must set your portal context by issuing the following command:

SQL> exec aersww_portalif.SetCTX(’portal schema’);

where portal schema is usually PORTAL30

3. Execute the Change Password function:

SQL>exec aersww_portalif.ChangePassword(user,old password,new password);

4. Enter the new user’s user group and user ID.

The user ID must conform to Oracle Username restrictions (30 characters). The user ID corresponds to the Oracle database user; AERS also captures the user name as an attribute of the user.

Changing the PORTAL30 PasswordThere are four steps to changing the PORTAL30 password for AERS:

1. Change the PORTAL30 password in the Oracle database.

a. Log on to SQL*Plus as a user with administrative rights or as the PORTAL30 user.

b. Type: alter user PORTAL30 identified by <new-password>;

c. Exit SQL*Plus.

2. Change the PORTAL30 password in PORTAL.

a. Log on to PORTAL as the PORTAL30 user using the original password.

b. Click on the Account Info link at the top right hand side of the page.

Managing passwords


c. Click on the Change Password link at the top right hand side of the page.

d. Enter the old password and the <new-password>.

e. Click OK.

f. Close the browser.

3. Change the stored password for PORTAL30 in the DAD definition.

a. Open a browser and navigate to: https://<middle tier (portal) machine>/pls/portal30/admin_/ and login as PORTAL30 with the new PORTAL30 password.

b. Click on Gateway Database Access Descriptor Settings <https://<middle tier (portal) machine>/pls/portal30/admin_/dadentries.htm> link.

c. Click on the "edit" icon next to the PORTAL30 Database Access DescriptorName toward the bottom of the page.

d. Enter the new password in the password field and click OK.

e. Close the browser.

4. Change the stored password for PORTAL30 on the Report Server.

a. Login to the Report Server machine.

b. Navigate to the <Oracle-9iDS-Home>\reports\conf directory.

c. Copy the <report-service>.conf file to <report-service>.old.

d. Open the <report-service>.conf in a text editor.

e. Identify the line: <property name="securityUserid" value="lyKAUY84+Xqn2krjZGGLs0DiBUs1RlY=" confidential="yes" encrypted="yes"/>

f. Replace the encrypted string for the "value" with the <new-password> for PORTAL30.

g. Replace the word yes with no for the "encrypted" variable.

h. Identify the line: <property name="portalUserid" value="lyKAUY84+Xqn2krjZGGLs0DiBUs1RlY=" confidential="yes" encrypted="yes"/>

i. Replace the encrypted string for the "value" with the <new-password> for PORTAL30.

j. Replace the word yes with no for the "encrypted" variable.

k. Save and close the file.

l. Restart the report service on the Report Server.

Data management 12-1

12Data management

This section covers the Oracle AERS data management tasks. These are:

■ Change reason codes

■ Duplicate checking

■ Copy Case

■ Data derivation procedures

■ Field code lists

■ Edit checks

■ Spell Check

■ Reconciliation

■ Clinical data extract file

Change reason codesEvery time you lock a case for modification, the system creates a change reason record. The change reason record contains a reason code and a free text description of the reason for the change. Oracle AERS allows you to control the contents of Modification Reason records with a number of configurable options.

Oracle AERS can prompt you to enter a change reason when you make an update, or you can configure the system to generate a record automatically by using system defaults. These system defaults are in the User Profile maintenance screen in the Administrator Console.

Each batch job (such as a submission report or Reconciliation) that updates case-related tables uses a parameter to determine reason codes that the system records. You can set this parameter in the program parameter; it is usually hidden.

TE_CASE_VERSION/TH_CASE_VERSION viewYou can count the AE_MOD_REASONS table entries to derive a case version number. To derive this number, configure the individual reason codes for either inclusion or exclusion from the count of updates (that is, specify which reason codes you want to include in a count).

Column Name Value Description

CASE_ID Case ID

Duplicate checking


Duplicate checkingOracle AERS checks the database for potential duplicate cases, in order to ensure a consistent database and to avoid multiple instances of the same case. You can invoke duplicate checking in either of two ways:

■ Select Actions=>Duplicate Case Check to perform duplicate checking manually.

■ Save a new case to perform duplicate checking automatically.

When there are possible duplicates, the duplicate check process presents the Duplicate Browse screen, which contains a list of possible duplicate cases. The Case Details panel displays the details of the highlighted case on the right.

Duplicate check APIThis section describes what the Duplicate Check API function does, its input parameters, and what it produces as output.

DescriptionThe Data Entry form uses the Duplicate Check API function to check for potential duplicate cases. The name of the function is DuplicateCaseCheck, a stored PL/SQL function in the database. The function checks the database for any cases based upon one or more criteria (expressed as queries), then inserts the Case IDs for any matching cases into table DTEMP. Based on the result, the function produces a configurable value.

Input parametersTable 12–1 shows the input parameters for the duplicate check API. All of these input parameters are from the Central Triage screen of the current case.

VERSION NUMBER Number Version #

Table 12–1 Input Parameters

Parameter Data Type Description

VSessionId IN number Oracle session ID

IvCaseId IN varchar2 Case ID

iRPT_SOURCE_TYPE IN varchar2 Case Source Type

iRPT_LAST_NAME IN varchar2 Reporter Last Name

EXT_CONTACT_LST_NAME IN varchar2 Contact Last Name

iEV_ONSET_DT IN varchar2 Event Onset Date

iEV_OCC_COUNTRY_CD IN varchar2 Country when Event Occurred

iSTUDY_ID IN varchar2 Study ID

iCENTER_ID IN varchar2 Center ID

iINVEST_ID IN varchar2 Investigator ID

iPATIENT_ID IN varchar2 Patient ID

iPT_INITLS IN varchar2 Patient Initials

Column Name Value Description

Duplicate checking


OutputThe duplicate check procedure outputs a varchar2 variable with one of the following values:

■ T – The duplicate check procedure found potential duplicate cases. The Data Entry form invokes the Duplicate Browse form, which in turn reads from the DTEMP table and displays the cases that are potential duplicates of the current case.

■ F – The duplicate check procedure found no duplicate cases. The Data Entry form issues a warning message on the Message Line indicating no duplicate cases were found ("Not a Duplicate Case").

■ X – The system did not execute duplicate check due to insufficient data, so it not execute any explicit searches for duplicates. This condition occurs if the data did not meet the minimum criteria for a search. The Entry form issues a warning message on the Message Line indicating duplicate search cannot be performed ("Cannot Perform Duplicate Check, Insufficient Data").

Duplicate Check logicDuplicate checking can be invoked two different ways. First, it can be performed manually by selecting the Check Duplicates push button (located on the bottom left corner of the Data Entry Case Login screen). Second, the duplicate case check is automatically performed when the user first saves the new case. AERS enforces that the duplicate check is run (either manually or automatically) prior to saving the case for the first time, and therefore before a case identifier is created for the new case.

The DuplicateCaseCheck function is created as a server side function and is called from the Data Entry form (E_ENTRY.FMB). The function has three outcomes: No duplicates found, Potential duplicates found (displayed on Duplicate Browse Screen), or, Could not execute check (due to incomplete data).

The criteria for defining potential duplicates depend on the nature case. For cases that are combinations of case types (e.g. an Adverse Event and a Product Complaint), the logic pertaining to each type is applied and a superset of cases qualifying as potential

iPT_DOB IN varchar2 Patient Date of Birth

iPT_AGE IN varchar2 Patient Age

iPT_AGE_UNIT IN varchar2 Patient Age Unit

iPT_SEX_CD IN varchar2 Patient Sex

iPROD_CD IN varchar2 Product Code

iRPT_VERBTM IN varchar2 Reporter Verbatim

iCOMPLAINT_CODE IN varchar2 Complaint Code

iLOT_NBR IN varchar2 Lot Number

iADVERSE_EVENT_FLAG IN varchar2 Adverse Event Flag

iPRODUCT_COMPLAINT_FLAG

IN varchar2 Product Complaint Flag

iSERVICE_COMPLAINT_FLAG

IN varchar2 Service Complaint Flag

iMEDICAL_INQUIRY_FLAG IN varchar2 Medical Inquiry Flag

Table 12–1 (Cont.) Input Parameters

Parameter Data Description

Duplicate checking


duplicates are presented. For example, if a case is marked as an AE and a PC, both sets of criteria are applied. The resulting set of potential duplicate cases presented to the user are the cases found by EITHER set of criteria.

The following criteria are included in the baseline configuration of AERS:

Clinical AE CasesClinical cases are evaluated by comparing the Drug Project, Country Where Event Occurred, Study ID, Patient ID, and Center ID. Only new cases with a Source Type = ‘C’ fire this algorithm. Clinical and Other Source Clinical Cases are evaluated as potential duplicates.

The logic for identifying potential duplicate clinical cases is as follows:

1. Adverse Event Flag True.

2. If the Study and Patient are known, match cases based upon the Study ID, Patient ID, Country Where Event Occurred, and Product Code. If all match, then the case is a potential duplicate.

3. Otherwise, if the Center ID and Patient ID are known, match case based upon the Center ID, Patient ID, Country Where Event Occurred, and Product Code. If all match, then the case is a potential duplicate.

4. Otherwise, do not execute the test because there is insufficient data to perform the test.

Non-Clinical AE Cases (Spontaneous, Registry, Literature, etc.)The critical fields captured at case creation are compared with existing values of non-clinical cases received within the last 90 days. A match on each field results in a value, according to the table below. The sum of all matching values for a case represents the duplicate score for the case. Only cases with a score greater than four (4) are displayed to the user as a potential duplicate.

Any case with an Adverse Event Flag = ‘Y’ and a primary source type other than ‘C’ fire this algorithm. Clinical cases (source type of ‘C’) are not evaluated as potential duplicates by this algorithm.

The check requires that both the Product Code and the Country Where Event Occurred have been entered into the new case. If they are not both present, Oracle AERS displays the message indicating that there is insufficient data to run the duplicate check.

Values of Fields Matched Non-Clinical AE Cases

Field Value if Matched

Product Code 2.0

Country Where Event Occurred 0.5

Patient Sex 1.0

Date of Event Onset (DD/MM/CCYY) 1.5

Date of Event Onset (MM/CCYY) 0.5

Reporter Last Name (first three letters) 1.0

Copy Case


Product Complaint CasesThe critical fields captured at case creation are compared with existing values of product complaint cases received within the last 90 days. A match on each field results in a value, according to the table below. The sum of all matching values for a case represents the duplicate score for the case. Only cases with a score greater than four (4) are displayed to the user as a potential duplicate.

Any case with the Product Complaint Flag = ‘Y’ fires this algorithm. Any case with the Product Complaint Flag = ‘Y’ is evaluated by the algorithm.

The check requires that both the Product Code and Complaint Code have been entered into the new case.

Values of Fields Matched for Product Complaints

Copy CaseThe front-end calls Copy Case, which AERS defines in the function DECopyCase.

Generic implementationTable 12–2 lists the data elements that the copy case function copies.

Field Value if Matched

Product Code 2.0

Complaint Code 1.0

Lot Number 1.0

Reporter Last Name (first three letters) 1.0

FUNCTION: DECopyCase

INPUT: Case ID, New Case ID

OUTPUT: Inserts data into tables specified in function.

Table 12–2 Copy Case Data Elements

Copied Table Copied Columns

AE_CASES CASE_ID

CASE_STS

CASE_TYPE

PROCESS_FLAG

DELETE_FLAG

FIRST_RCVD_DT

VALIDATION_REQD_FLAG

RECONCILIATION_STS

PROD_CD

CASE_OWNER_USR_GRP_ID

PROJECT_DRUG_NAME

DRUG_FORM

DRUG_DID

DRUG_PROJECT_TID

DICT_UNMAPD_FLAG

GENERIC_NAME

DRUG_CLASS

PREFERRED_DRUG_PROJECT_NAME

RISK_FACTOR_CMNT

PER_SFTY_UP_RPT_CMNT

PHARMACOVIGILANCE_CMNT

EV_OCC_COUNTRY_CD

Copy Case


AE_EVENTS CASE_ID

EVENT_SEQ_NBR

DISPLAY_NBR

PRIMARY_IND

RPT_VERBTM

CO_VERBTM

PREFERRED_EVENT_TERM

BODY_SYSTEM

SUB_BODY

MID_LVL_TERM

EVENT_DID

EVENT_TID

DICT_UNMAPD_FLAG

CO_ADDED_TERM_FLAG

SERIOUS_FLAG

FROM_DT

TO_DT

ONGOING_FLAG

DURATION

DURATION_UNIT

OUTCOME_CD

THERAPY_FLAG

THERAPY_TEXT

US_UNEXPECTED_FLAG

CORE_UNEXPECTED_ FLAG

AE_SUSPECT_DRUGS

CASE_ID

SUSP_DRG_SEQ_NBR

DRUG_NAME

DRUG_DID

SUSPECT_DRUG_TID

DICT_UNMAPD_FLAG

GENERIC_NAME

DRUG_CLASS

PREFERRED_DRUG_NAME

DISPLAY_NBR

PRIMARY_FLAG

DRUG_COMPANY_FLAG

OVER_COUNTER_FLAG

ACTION_TAKEN

REASON_FOR_ACTION

LOT_NBR

EXP_DT

NDC_NBR

PRODUCT_PROBLEM_FLAG

PROD_PROB_QA_NUMBER

CUM_DOSE

CUM_DOSE_UNIT

ABATE_FLAG

REAPPEARED_FLAG

PRIOR_USE_FLAG

TOLERATED_FLAG

RECHALLENGED_FLAG

DUR_OF_TRTMT_TO_EV

DUR_OF_TRTMT_TO_EV_UNIT

TOTAL_DUR_OF_TRTMT

TOTAL_DUR_OF_TRTMT_UNIT

ROUTE_CHILD_CD

PURCH_COUNTRY_CD

DRUG_INTERACTION_FLAG

REPORTER_CAUSE_TYPE

RELATEDNESS_CD

RPT_RELATEDNESS_CD

CUM_DOSE_CHR

AE_INDICATIONS CASE_ID

SUSP_DRG_SEQ_NBR

INDIC_SEQ_NBR

INDICATION

INDICATION_CODE

DX_DID

INDICATION_TID

DICT_UNMAPD_FLAG

Table 12–2 (Cont.) Copy Case Data Elements

Copied Table Copied Columns (Cont.)

Copy Case


AE_DOSAGES CASE_ID

SUSP_DRG_SEQ_NBR

DSG_SEQ_NBR

DOSE

DOSE_UNIT

FREQUENCY

ROUTE

DRUG_FORM

DOSE_STRENGTH

DOSE_STRENGTH_UNIT

FROM_DT

TO_DT

DURATION

DURATION_UNIT

CLOSEST_TO_EV_FLAG

DOSE_CHR

DOSE_STRENGTH_CHR

AE_EVENTS_TO_DRGS

CASE_ID

SUSP_DRG_SEQ_NBR

EVENT_SEQ_NBR

RELATEDNESS_CD

RPT_RELATEDNESS_CD

US_UNEXPECTED_FLAG

CORE_UNEXPECTED_FLAG

AE_CASE_RPT_FRM_LOGS

CASE_ID

CS_LOG_SEQ_NBR

RCVD_DT

RCVD_BY_FRST_NAME

RCVD_BY_LST_NAME

RCVD_BY_POSITION

PREP_DT

PREP_BY_FRST_NAME

PREP_BY_LST_NAME

PREP_BY_COMPANY

PREP_BY_CITY_NAME

PREP_BY_COUNTRY_CD

PROCESSED_IN_SFTY_DT

REV_FRST_NAME

REV_LST_NAME

REVIEW_DT

LOG_IN_COMMENTS_TEXT



Data derivation procedures


Data derivation proceduresOracle AERS provides two data derivation procedures: Case ID generation and Case data derivations.

Case ID generationAn adverse event reporting system requires accurate tracking of cases. When you enter a new case, Oracle AERS automatically generates its Case ID. Case IDs are unique throughout all sites in an Oracle AERS installation. Users may not modify a Case ID: it is a display-only field.

The structure of Oracle AERS allows for the generation, retrieval, and display of a client-specific Case ID format, with the restriction that Case IDs are unique within the entire system.

AE_REPORT_SOURCES

CASE_ID

RPT_SEQ_NBR

PRINCIPAL_INVEST

NON_CO_STUDY_SPONSOR

RPT_SOURCE_TYPE

REGISTRY_NAME

REGISTRY_NBR

LITERATURE_DESC

LIT_ISSUE_DT

LIT_VOLUME

LIT_PAGE

RPT_ID

NON_CO_STUDY_DESC

RPT_FRST_NAME

RPT_LST_NAME

RPT_MID_INITIAL

RPT_TITLE

HEALTH_PROF_FLAG

CONSUMER_FLAG

PRIMARY_REPORTER_IND

RPT_ORG_NAME

RPT_ADDR1

RPT_ADDR2

RPT_ADDR3

RPT_ADDR4

RPT_CITY_NAME

RPT_STATE_CD

RPT_ZIP_CD

RPT_COUNTRY_CD

RPT_PHONE

RPT_FAX

RPT_EMAIL

RPT_OCCUPATION

RPT_SPECIALTY_DESC

WRK_HOSP_FLAG

RPT_IS_PATIENT_FLAG

OTHER_PATIENT_ID

AE_RLVNT_APPROVALS

CASE_ID

SUSP_DRG_SEQ_NBR

RLVNT_APPR_SEQ_NBR

LIC_NBR

LIC_TYPE

VW_COMPANY_NARRATIVE,

VW_REPORTER_NARRATIVE

CASE_ID

FIELD_NAME

FIELD_VALUE





Updating the Case ID generation algorithm

Case data derivationsThe Data Entry subsystem derives the values for some fields. You cannot configure the rules for these derivations. There are two types of derived fields:

■ Oracle AERS does not store temporary derived fields in the database, and derives them on-the-fly each time you trigger the event.

■ Oracle AERS stores updatable derived fields in the database. You can change the derived value if the field is accessible. The system updates some derived fields as the user enters data, and derives other fields by command.

The system derives AutoDerived fields when the WHEN_VALIDATE_… trigger fires for any of the source fields. The system passes the values of all the relevant fields to the procedure, then stores the returned values from the procedures in the derived fields. This procedure is an extension of how dictionary mapping works to include other fields.

The system executes another type of generation on demand. These derivations work across multiple records, such as the seriousness and labeledness roll-up fields.

Field/Record/Record block, DB derivationsThe system triggers Field Level Derivations by the validate field trigger. Record-level derivations occur on the WHEN-VALIDATE-RECORD trigger. Record Block (RB) is a special type of record-level derivation, which requires looking at all the records in the block. Oracle Forms only allows the program to access the current record during the execution of the WHEN-VALIDATE-RECORD trigger, therefore, RB derivation requires special logic. The most promising technique is to store all the records in a record group and run the derivation logic from there. You can perform database derivations using database tools like views and stored procedures.

At a minimum, the system recalculates derived fields supported by views when you save the case.

Updating and compiling the derivation libraryThe customizable library is called E_CUSTOM.PLL. You must have access to Oracle Forms to update this library: contact your System Administrator or Oracle for the correct version of Oracle Forms. Using a different version of Oracle Forms to update, compile and generate the E_CUSTOM.PLL may not work with your current version of Oracle AERS.

The following steps describe how to update and compile the procedure/function in the E_CUSTOM.PLL.

1. Run the Oracle Forms Builder.

2. Connect to the Oracle AERS Database as schema owner or any user_id which have access to all the Oracle AERS database objects.

3. Open E_CUSTOM.PLL

Function Name GENERATECASEID

Return Type VARCHAR32

Input None

Output Description Unique Case ID



4. Identify the procedure/function you want to update.

5. Change, compile, and save.

Table 12–3 lists the procedures in the E_CUSTOM.PLL library.

Generating the libraryTo generate the library, you need to run the Oracle Forms Generate. The following steps describe how to generate the procedure/function in the E_CUSTOM.PLL.

1. Run the Oracle Forms Generate.

2. Enter the filename, including the path.

3. Enter the user_id, password, and database instance name.

4. Select LIBRARY as module type.

5. Select FILE as module access.

For more information about how to use Oracle Forms Builder/Generate, refer to the Oracle Forms documentation.

Table 12–3 E_CUSTOM.PLL Procedures

Procedure Name Description

CUSTCaseType This procedure derives the Case Type.

CustDataDiscrepancyExists This procedure derives if Data Discrepancy records exist.

CustDerivePatientAge This procedure derives the patient age at onset.

CustExportStatus This procedure derives the export status.

CustInitialDt.FirstRcvdDt This procedure derives the initial received date (the topmost date in the Initial Date block) from the AE_CASE_RPT_FRM_LOGS table.

CustInitialDt.FirstPrepDt This procedure derives the initial prepared date (the second date in the Initial Date block) from the AE_CASE_RPT_FRM_LOGS table.

CustInitialDt.FirstProcDt This procedure derives the initial processed date (the third date in the Initial Date block) from the AE_CASE_RPT_FRM_LOGS table.

CustInitialDt.FirstRevwDt This procedure derives the initial reviewed date (the fourth date in the Initial Date block) from the AE_CASE_RPT_FRM_LOGS table.

CustFollowUpCase This procedure derives the follow-up case from the AE_CASE_RPT_FRM_LOGS table.

CustMarkExportStatus This procedure derives the marked export status.

CustReconDiscrepancyExists This procedure derives if Reconciliation Discrepancy records exist.

CustRollUpToCase This procedure handles the roll-up derivation of seriousness, relatedness, and expectedness to the case level.

CustRollUpToDrug This procedure rollups the Reporter and Company relatedness code to the drug level.

CustRollUpToEvent This procedure rollups the serious_flag, us_unexpected_flag, and core_unexpected_flag to the event-level.

CustSubmissionDueDt This procedure derives the submission due date for agency/report form.



Standard derivation proceduresTable 12–4 summarizes the standard derivation procedures.

Table 12–4 Standard Derivation Procedures

Field Source Fields Description

Age in Years Age/Age Units Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

Height in CM Height/Ht Units Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

Weight in Kg Weight/Wt Units Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

Age at Onset/Age at Onset Years

DOB, Onset Date Fld: Field derivation triggers the derivation.Cust: The derivation is customizable.PLL: Oracle AERS stores the derivation logic in the Forms library.Stored: Oracle AERS stores the derivation result in the database.

Submission. Due Date Initial received date, Agency/Report Form

Fld: Field derivation triggers the derivation.Cust: The derivation is customizable.PLL: Oracle AERS stores the derivation logic in the Forms library.Stored: Oracle AERS stores the derivation result in the database.

Initial Received Date RPT_FRM_LOG.RECEIVED_ DATA, SEQ_NBR

Fld: Field derivation triggers the derivation.Cust: The derivation is customizable.PLL: Oracle AERS stores the derivation logic in the Forms library.Stored: Oracle AERS stores the derivation result in the database.

Initial Processed Date RPT_FRM_LOG. PROCESS_date

Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

Initial Review Date RPT_FRM_LOG.Review_date

Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Temp: Oracle AERS does not store the derivation result in the database; AERS derives the result "on-the-fly."

Product Code CASE_TYPE, PRODUCT_ DRUG, SUSPECT_DRUG (display_nbr = 1).PREFERRED DRUG NAME, FORM


Version # MOD_REASON_CD Cust: The derivation is customizable.V: Oracle AERS stores the derivation result in the view.Temp: Oracle AERS does not store the derivation result in the database; AERS derives the result "on-the-fly."



SUBMISSION NUMBER

SUBMISSION NUMBER Rec: The Record-level triggers the derivation.EN: The derivation is not customizable (Core).V: Oracle AERS stores the derivation result in the view.Stored: Oracle AERS stores the derivation result in the database.

Review Required CASE STATUS Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

MOD_REASON/ MOD_REASSON_CD

Triggered at get lock time.

Case Level Seriousness, Unexpectedness, and Relatedness

Any events, drugs, and event-drugs level data

Cust: The derivation is customizable.PLL: Oracle AERS stores the derivation logic in the Forms library.Stored: Oracle AERS stores the derivation result in the database.

Drug Level Relatedness

Any event-drugs level data


Event Level Seriousness, Unexpectedness

Any event-drugs level data


Reconciliation Status Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

MOD_DEATH_STS_DT

AE_CASES.DIED_FLAG Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

MOD_SERIOUS_FLAG_DT

AE_CASES.SERIOUS Fld: Field derivation triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

MOD_CO_ASSESSMENT_DT

CO_ASSESS_RELATED_FLAG


MOD_REPORTER_CAUSE

REPORTER_CAUSE_TYPE


Data Discrepancy Existence of Under Review Data Discrepancies

Cust: The derivation is customizable.PLL: Oracle AERS stores the derivation logic in the Forms library.Temp: Oracle AERS does not store the derivation result in the database; AERS derives the result "on-the-fly."

Table 12–4 (Cont.) Standard Derivation Procedures

Field (Cont.) Source Fields (Cont.) Description

Field code lists


Field code listsYou can associate each text field in Oracle AERS with a code list. Code lists, also known as Lists of Values, serve as reference lists for the acceptable values for the field.

You can use the code list to enforce values in a field in the following ways:

■ Use the code list to enforce the values in a field, in which case the user must enter a value from the list in order to capture data in the field

■ Use the code list as a warning, in which case users are alerted that the entered value is not in the list, but allowed to continue

■ Use the code list as a passive reference to assist data capture.

You can represent each code list value in multiple languages, to support the capture and generation of local, native language reports.

Oracle AERS includes a Code List Maintenance facility to manage code lists across your installation. In addition, you can base code lists upon any valid SQL statement. Basing a code list on a SQL statement enables you to look up data values against external systems that are accessible to Oracle AERS, such as manufacturing systems, clinical data management systems, or clinical trials management systems.

This section describes the following ways you can use code lists to configure Oracle AERS:

■ Adding new code lists

■ Creating SQL lookup code lists

■ Updating existing code lists

■ Deleting code lists

■ Deleting individual code list items

Reconciliation Discrepancy

Existence of under Review Reconciliation Discrepancy

Cust: The derivation is customizable.PLL: Oracle AERS stores the derivation logic in the Forms library.Temp: Oracle AERS does not store the derivation result in the database; AERS derives the result "on-the-fly."

EVENT_TO_DRUG.XXX_ LABELLED

SUSPECT_DRUG.PREFERED NAME and EVENT.PREFERED_ TERM

Rec: The Record-level triggers the derivation.EN: The derivation is not customizable (Core).Stored: Oracle AERS stores the derivation result in the database.

MedWatch Case SOURCES.Registry Name Cust: The derivation is customizable.V: Oracle AERS stores the derivation result in the view.Temp: Oracle AERS does not store the derivation result in the database; AERS derives the result "on-the-fly."

Initial/Follow-up Count of case AE_CASE_RPT_ FRM_LOGS records.

Rec: The Record-level triggers the derivation.Cust: The derivation is customizable.PLL: Oracle AERS stores the derivation logic in the Forms library.Temp: Oracle AERS does not store the derivation result in the database; AERS derives the result "on-the-fly."

Table 12–4 (Cont.) Standard Derivation Procedures

Field (Cont.) Source Fields (Cont.) Description

Field code lists


Adding new code listsIf Oracle AERS does not contain a specific code list that you want to use in your configuration, you may add that new list and assign it to the fields as desired. The complete process takes four steps:

1. Create the new code list using the Oracle AERS Global Maintenance subsystem.

2. Add individual code list items to the newly created list.

3. Create a Record Group corresponding to the new Code List.

4. Assign the code list to a field.

Step 1: Create the new code listTo add a code list to the Oracle AERS Code List tables:


2. Select the Code Lists tab from the main window.

The Code List Maintenance screen displays.

3. Click the Add Row button.

4. Enter values in the following fields:

■ Code List Name: The name of the code list that you are creating.

■ Custom Permission Type: Set the value to "C" for customizable ("S" is reserved for System code lists).

■ Description: A free text description of the code list.

5. Click the Save button, or press F10, to save the code list.

Oracle AERS saves the code list to the database.

Step 2: Add individual code list itemsTo add an item to a code list:

1. If it is not already open, launch the Oracle AERS Global Maintenance subsystem.

2. Select Code Lists tab from the main screen.

The Code List Maintenance screen displays with a list of code lists.

3. Select the code list from the Navigator panel.

4. Click in the Code field.

5. Enter the following values into the fields.

■ Code: The short value that is stored in the database.

■ Code Value Text: The value that is displayed to the user or used in reports.

■ Lang: The Code Value Text language. You can translate each code list value into the local languages required for your users or local reporting. Oracle

Note: At this point, you can proceed to "Step 2: Add individual code list items" to add the code list items to the new code list, or continue to the next step to save the code list before adding code list items.

Field code lists


AERS also includes specific, reserved languages (RPT, E2B, ISO, and UPL) for coding purposes.

■ Display #: The display order of the values within the List of Values dialog box in data entry and query.

■ Retired: A retired code list value is one that exists in your data, but that you no longer wish to use to code new data. Code lists are retired when you change your coding standards, either in conjunction with the implementation of Oracle AERS, or as business practices or regulations change. (See "Retiring code list values" on page 11-20).

■ Customizable: A checked Customizable checkbox indicates the User may update the code list codes. An unchecked Customizable checkbox indicates the User should not make entries or changes to the code list codes. System codes should not be checked customizable.

■ User Enterable: A checked User Enterable checkbox indicates the code list value displays in the LOV box and you can select it. An unchecked User Enterable checkbox indicates the code list value does not display in the LOV, and it is not available to you for selection. Additionally, you cannot manually enter the code list value in the field.


Oracle AERS saves the new code list item to the database.

Step 3: Create a Record GroupOracle AERS uses Oracle Forms Record Groups in order to dynamically display the code list values from the Data Entry and Query Subsystems. Because of this organization, each Code List must have a corresponding Record Group.

To add a Record Group Attribute:

1. Launch the Oracle AERS Field Attributes form by selecting Help=>FAT Configuration.

2. Press the Define Record Groups button on the main screen.

3. Enter the following information:

■ Code List Name: The name of the new code list.

■ Code List Exectbl Text: Leave blank for code lists that are maintained in the Global Maintenance tables (more on this column in next section, Creating SQL Lookup Code Lists).

■ Refresh Flag: unchecked.

■ Lov Name: COMMON_3_COLUMN_LOV.



6. Exit the Field Attributes form (if done).

Step 4: Assigning code lists to fieldsTo assign a code list to a field:

1. Place the cursor in the field you wish to add the code list to.

2. Select Help=> FAT Configuration.

Field code lists


3. Double-click in the Code List field to display the available code lists.

4. Select the code list name and click OK.

The Code List name is populated in the Code List field.


Define LOV Column MappingOnce you link a code list to a field, you can customize the appearance of the code list in the lower block of the Define LOV Column Mappings window. You access this screen through the Field Attributes form, by clicking the Define LOV Column button.

The following are the default settings, but you can customize them based on your needs:

■ Column # - The number of columns that are displayed in the code list.

■ Title - The name of the column.

■ Width - The width of the column.

■ Return Item - The field name where the value is copied to.

Creating SQL lookup code listsIn addition to using standard code lists from the Global Maintenance tables, Oracle AERS supports creating code lists based upon any valid SQL statement. The syntax for the Select statement is specific and you must follow it precisely, but the rest of the query can utilize any standard SQL feature.

The basic syntax of a SQL lookup is:

select column_name COL1, column_name COL2

from table_name...

where the column aliases COL1...COLn are required elements. The values that Oracle AERS displays to the user, their labels, and the return items are defined in the Field LOV Column Mapping table (accessed from the Define LOV Mapping button from the

Field code lists


Field Attributes Form). When designing the lookup, you should include all of the columns that may be returned by any of the fields that reference this codelist.

Once you have written the SQL statement, create a record group for it by performing the following steps:

1. Launch the Oracle AERS Field Attributes form.

2. Click the Record Groups button.

3. Create a new record by pressing F6 and enter the details as follows:

■ Codelist: The name of the codelist that the Field Attributes references

■ Codelist Executbl Text: Enter the SQL statement that forms the basis for the lookup.

■ Refresh Flag: Whether the LOV is executed each time the user presses the F9 key. For SQL-based record groups, this value should always be Y.

■ LOV Name: The name of the Forms LOV object you want to invoke. The system predefines these objects as follows:

COMMON_n_COLUMN_LOV: The standard LOV behavior. Oracle AERS validates values against the first column in the LOV. When you name the LOV, set the value n to the number of columns in the resulting query. AERS can support up to 24 columns.

COMMON_3_COLUMN_R_LOV: This LOV behaves like a standard LOV except that field validation executes against the second column rather than the first.

COMMON_n_COLUMN_FLOV: The LOV is a "Filter Before Display" LOV, which is useful when the lists are very long because it invokes the LOV display but does not fetch values until a user enters "filter" criteria. Supports n=1 to 6.

Filter Before Display groups require a slightly different SQL structure:

select COL1, COL2, ... COL6 from (select column_name COL column_name COL2, ... column_name COL6 from table_name...)

4. Press F10 to save changes and close the window.


Updating existing code listsYou may choose to modify the existing Code List Values as desired by any of the following procedures:

■ Updating an item in a code list

■ Retiring code list values

■ Reactivating retired individual code list items

Updating an item in a code listTo update an item in a code list:

Note: When modifying existing lists that contain RPT, UPL, ISO, or E2B language values, you must ensure that each item you alter is represented by a corresponding entry in these languages.

Field code lists



2. Select the Code Lists tab.


3. Select the code list containing the code you want to update from the Navigator panel.

The code information displays.

4. Select the code you want to update.

5. Enter the appropriate changes.



Retiring code list valuesYou can inactivate a code list item in an LOV by retiring the item. The code remains valid in the database, and you may reactivate it for selection at any time. The retired item still appears in the code list (with the designation "Y" under the "Retired" column of the code list), but users cannot select it. Because deleting items within a code list may result in orphan data if Oracle AERS has captured data against it, you should retire the code list item.

To retire an item in a code list:




3. Select the code list containing the code you want to retire.


4. Select the code you want to retire.

5. Click the Retired checkbox to display a check mark.


Reactivating retired individual code list itemsTo reactivate a retired item in a code list:




3. Select the code list containing the code you want to reactivate.


4. Select the code you want to reactivate.

5. Click the Retired checkbox to remove the retired check mark.


Deleting code listsTo delete a code list:

Edit checks





3. Select the code list you want to delete.

4. Click the Delete button.

The code list disappears from the screen.


Oracle AERS does not prompt you, and deletes the code list and its associated code list values from the database.

Deleting individual code list items

To delete an item in a code list:




3. Select the code list containing the code you want to delete.


The code disappears from the screen.


Oracle AERS does not prompt you, and deletes the code list value from the database.

Edit checksEdit checks are the data-integrity rules that check the validity and consistency of the data that users are entering. The edit checks are Oracle AERS’ main mechanism to ensure the integrity of adverse event data. Some of these rules are a part of the core Oracle AERS product, while you or your company can specify others.

There are two different sets of rules for determining when an edit check fires:

■ Type of event that triggers the check

■ Mode in which the data is entered

In the online screen edit there are several different events which cause edit rules to fire.

Field checksField checks fire when the user modifies the data in a field and the focus (cursor) leaves the field. Field edits are defined in the FAT and not specified in this guide. In Oracle AERS, because the user has the option to bypass a window or field, mandatory

Caution: You should retire items within code lists (see "Retiring code list values" on page 11-20) rather than deleting them. Deleting items within code lists may result in orphan data if data has been captured against the code list item.

Edit checks


checks must be performed at the record-or case-level (wherever is appropriate to that check).

Record checksRecord checks fire when the user modifies any data in a record and shifts the focus outside the record.

Case SaveCase Save fires when the user has modified any data in the case and explicitly invokes the save option.

Case ExitCase Exit fires when the user has modified any data in the case and exits (e.g., selects another case, closes the Data Entry form, or exits Oracle AERS).

Batch Edit CheckingThis process runs in the background from the Oracle AERS batch edit report. All Soft edit checks fire in batch mode.

Updating the edit check programYou program all custom edit rules in a PL/SQL package CustomEditRules in the database. The package, in turn, defines each rule in a separate procedure. Table 12–5 describes the parameters for the procedure.

Table descriptionsThis section describes the RULE_ATTRIBUTES table and the RULE_FIRING_MODES table.

Table 12–5 CustomEditRules Parameters

Parameter Data Type Description

ivRecordString/ivCaseID

IN VARCHAR2 Record-String for record level checks or Case-ID for case level checks. A record string is a string of all concatenated field values of that record, separated by ‘|’

ivRuleName IN VARCHAR2 Name of the edit rule

ivParentValue IN VARCHAR2 Parent Logical Key value of the rule

inErrorCd IN NUMBER Error code of the rule

ovErrorFlag OUT VARCHAR2 Error Flag. ‘Y’ (rule fails); ‘N’ (successful)

ovErrorText OUT VARCHAR2 The returned error text of the edit check

ionChildSeqNbr IN OUT NUMBER

Child sequence number of the offending record (for example, the EVENT_SEQ_NBR of the AE_EVENTS event record)

IonGrandChildSeq Nbr

IN OUT NUMBER

Grandchild sequence number of the offending record (i.e., the DSG_SEQ_NBR of a dosage in AE_DOSAGES for a suspected drug)

iovCurPosition IN OUT VARCHAR2

Cursor position of the front-end when the rule fails

ovDiscrep_values

OUT VARCHAR2 String of field values which violate the edit rule

Edit checks


RULE_ATTRIBUTES tableThe RULE_ATTRIBUTES table helps to control the execution of the edit rules. It is primarily used by the edit check routines themselves, so most of the code that implements the functions behind this table is the responsibility of the client. The following table provides a standard way to handle some of the responsibilities of the error check logic.

RULE_FIRING_MODES tableThis table contains Workflow Tasks in which the rule fires. This table is an intersection table between RULE_ATTRIBUTES and DATA_ENTRY_MODES.

Table 12–6 RULE_ATTRIBUTES Table

Field Name Description

TABLE_NAME The name of the table. For case-level edit checks this field contains one blank (instead of Null).

RULE_NAME The name of the rule being checked.

RULE_TYPE Rule (edit check) type: C (case-level “save” edit check), E (case-level “exit” edit check), R (record-level edit check), X (for reconciliation). For Case-Exit (E) type, SOFT_RULE_FLAG must be ‘Y’

EXECTBL_PROCEDURE Procedure in which this rule is implemented

INTERNAL_SEQ_NBR Rule number used by the API to loop through the rules (has no meaning outside of the API)

WINDOW_NAME Not used in Oracle AERS 4.5

SEVERITY_CD Severity of the rule failure (used in reporting)

RULE_ALIAS Client’s name for the rule (can be used in reporting)

CURSOR_POSITION The position to place the cursor if the user wants to fix the data

ERROR_CD Oracle AERS error code for the user message displayed when the rule fails

ACTIVE_FLAG Flag indicating if the rule is active

SOFT_RULE_FLAG Indicates this rule may not need to be strictly enforced

DISCREP_SOURCE Source of discrepancy: D (data) or R (reconciliation)

Note: You must consider the work process when you determine edit firing. For example, you should not run case-level checks before you enter an adequate amount of data on a form.

Table 12–7 RULE_FIRING_MODES Table


TABLE_NAME Table name. For case-level edit checks this field contains one blank (instead of Null)

RULE_NAME Rule name checked

DE_MODE Workflow Task in which the rule is fired

RECORD_STS Record status for Workflow Task: N (new), U (update)

Spell Check


Example 12–1 Edit check example

This example describes how to implement an edit check to ensure that the prepared date of case login is on or after the received date. Because the system stores these two dates in the same table (AE_CASE_RPT_FRM_LOGS) and you usually enter them at the same time, you can implement their entry as a record-level Hard edit check. If you implement the edit rule in a procedure (PREP_DATE_AFTER_RCVD_DATE) in the CustomEditRules PL/SQL package, you should add the following record in the RULE_ATTRIBUTES table.

(Where NBF_PREP_DT is the item name in block AE_CASE_RPT_FRM_LOGS in the Data Entry Form.) Oracle AERS positions the cursor in this field when the rule fails. The system displays the error message stored in the ERROR_MSGS table corresponding to error code -40047 when this rule is violated. Other optional fields are left Null in this example.

If you want this edit rule to fire under the LOGIN-new, LOGIN-update, DE, and ASSESS Workflow Tasks, you must add the following four records to the RULE_FIRING_MODES table.

Spell CheckThe standard Oracle AERS configuration supports spell check using Microsoft Word from a user’s desktop machine via ActiveX. Oracle AERS is also configured to

Field Name Value

RULE_NAME PREP_DATE_AFTER_RCVD_DATE

RULE_TYPE R

EXECTBL_PROCEDURE CUSTOMEDITRULES.PREP_DATE_AFTER_RCVD_ DATE

INTERNAL_SEQ_NBR 1

WINDOW_NAME

SEVERITY_CD

RULE_ALIAS

CURSOR_POSITION AE_CASE_RPT_FRM_LOGS.NBF_PREP_DT

ERROR_CD -40047

ACTIVE_FLAG Y

SOFT_RULE_FLAG N

DISCREP_SOURCE D

TABLE_NAME RULE_NAME DE_MODE RECORD_STS


PREP_DATE_AFTER_ RCVD_DATE

LOGIN N



LOGIN U



DE U



ASSESS U

Spell Check


integrate with JSpell. However, it must be purchased by your company and installed on the server.

Configuring for Microsoft WordIf your corporate web-browsing standard prohibits downloading ActiveX controls, we suggest you define the Oracle AERS middle-tier server as a trusted site, and adjust your ActiveX controls to permit downloads from trusted sites.

Add Oracle AERS middle-tier server as a trusted site:1. From your web browser, navigate to Tools=>Internet Options=>Security.

2. Highlight Trusted Sites, and click the Sites button.

The Trusted Sites dialog box displays.

3. Add the web site address of your middle-tier server, and click OK.

4. Click OK.

Enable ActiveX:1. From your web browser, navigate to Tools=>Internet Options=>Security.

2. Click the Custom Level button.

3. 'Initialize and script ActiveX controls not marked as safe' must not be set to DISABLED.

4. Click OK.

Installing JSpell in Oracle AERSThis section describes how you can configure Oracle AERS to implement JSpell.

1. Purchase the JSpell software. Ensure that the version is compatible to JDK 1.1. You need to license the JSpell Java SDK based on the number of users that are performing spell checking. Site-wide licenses are very reasonably priced.

2. The AERS front end installer deposits the necessary JSpell files on the 10gAS server. From the 10gAS server, in the <10gAS_Home>\forms90\java directory, copy the following files: JSpellIntegration.jar, jspell2w_java11.jar and SNDSPELL.JDX to the 9iAS server directory <806_Home>\FORMS60\java.

3. Shut down the Apache Server (OracleiSuitesHTTPServer) on the application server.

4. In the <806_Home>\FORMS60\server directory, create a file called jspell.properties. This file should contain the following 2 lines (replace <806_Home> with the Oracle 806 Home of the 9iAS, e.g. D:\\Oracle\\806):

■ index=<806_Home>\\FORMS60\\java\\SNDSPELL.JDX

Note: A user's spell-check settings should not be set to "ignore words in UPPERCASE" to be able to spell-check uppercase words in Oracle AERS.

Note: <806_Home> is the Oracle 806 Home of the 9iAS, e.g. D:\Oracle\806)

Reconciliation


■ log=<806_Home>\\FORMS60\\java\\jspell.log

5. In the <iSuites_Home>\Apache\Jserv\servlets directory, add the following three lines at the end of file zone.properties (replace <806_Home> with the Oracle 806 Home of the 9iAS, e.g. D:\Oracle\806):

■ #JSpell

■ servlet.jspell.initArgs=propertiesFile=<806_Home>\forms60\server\jspell.properties

■ servlet.jspell.code=com.wallstreetwise.app.jspell.domain.net.JSpellServlet

6. In directory <iSuites_Home>\Apache\Jserv\conf, add the following 3 lines at the end of file jserv.properties (replace <806_Home> with the Oracle 806 Home of the 9iAS, e.g. D:\Oracle\806):

■ #JSpell

■ wrapper.classpath=<806_Home>\forms60\java\JSpellIntegration.jar

■ wrapper.classpath=<806_Home>\forms60\java\jspell2w_java11.jar

7. Restart the Apache Server (OracleiSuitesHTTPServer) on the 9iAS application server.

AS10g Forms Server configuration1. Edit the file formsweb.cfg in directory <AS10g_Home>\forms90\server. Within

the section [aers45], modify the line archive_jini=f90all_jinit.jar,opaicons.jar,aersicons.jar,timeout.jar by appending jspell2n_java11.jar,JSpellIntegration.jar to the end of line. i.e. it becomes:

■ archive_jini= f90all_jinit.jar,opaicons.jar,aersicons.jar,timeout.jar,jspell2n_java11.jar, JSpellIntegration.jar

2. If the AS10g server is installed on a machine separates from the 9iAS server, one more step is needed. The files jspell2n_java11.jar and JSpellIntegration.jar, located in directory <10gAS_Home>\forms90\java, have to be signed. You may refer to Oracle white paper Oracle 9i Forms: JAR File Signing for JInitiator 1.3 for instructions in signing jar files.

ReconciliationThe reconciliation component of Oracle AERS can provide the tools to support the reconciliation of adverse event data in Oracle AERS with Clinical Data Management (CDM) systems. The Reconciliation component addresses the need to compare the demographic, drug dosing, and event profiles in Oracle AERS and the CDM systems for a particular trial's patient.

Modifying ReconciliationYou can customize the Oracle AERS Reconciliation subsystem in the following areas:

■ You can custom write the process for extracting data to load into the staging database.

Note: The double back-slashes are required (for this file only).

Reconciliation


■ You can turn the reconciliation rules off and on; however, there are some assumptions to this feature. For example, it does not make sense to turn off the NO_PROJECT_DATA rule. Table 11–8 summarizes the reconciliation rules.

Table 12–8 Reconciliation Rules

Rule Name Condition

NO_PROJECT_DATA There is no project data for this patient, study and center.

COMPARE_HEIGHT If both fields exist, the data for the vitals measurement closest to the event should match.

COMPARE_WEIGHT If both fields exist, the data for the vitals measurement closest to the event should match within 10%.

COMPARE_FIELDS The general rule is that corresponding fields must have the same value. It is only enforced if both values exist and the key fields match. The fields that are affected by this rule are:

AE_CAUSE_OF_DEATH.ICD

AE_CASES.DIED_FLAG

AE_CASES.DEATH_DT

AE_CASES.PT_DOB

AE_CASES.PT_SEX_CD

AE_CASES.PT_RACE_CD

AE_CASES.SERIOUS_FLAG

AE_DOSAGES.DOSE_UNIT

AE_DOSAGES.DOSE

AE_DOSAGES.TO_DT

AE_DOSAGES.ROUTE

AE_DOSAGES.DRUG_FORM

AE_SUSPECT_DRUGS.PREFERRED_DRUG_NAME

AE_AE_DOSAGES.FREQUENCY

AE_SUSPECT_DRUG.ACTION_TAKEN

COMPARE_SERIOUS If the adverse event is marked serious and the project data serious count is zero, raise an error.

MISSING_RCN_ICD Cause of death data exists in the adverse event which is absent in the project.

MISSING_AE_CAUSE_OF_ DEATH

Cause of death data exists in the project, which is absent in the adverse event.

NULL_ICD An ICD for cause of death had a NULL value and could not be reconciled.

NULL_DOSING_KEY The key fields in the adverse event data are NULL. Error should be corrected before reconciliation. The keys are PREFERRED DRUG NAME, FROM DT, DRUG FORM.

MISSING_RCN_ DOSING

Dosing data which exists in the adverse event does not exist in the project data. The keys are PREFERRED DRUG NAME, FROM DT, DRUG FORM.

MISSING_AE_DOSING Dosing data which exists in the adverse event does not exist in the project data. The keys are PREFERRED DRUG NAME, FROM DT, DRUG FORM.

POST_THERAPY The EV_ONSET_DT date is after the final visit date. If this condition exists, the system raises no further discrepancies.

Reconciliation


Staging tablesThe staging database contains a subset of the data in the CDM system. The method of extracting and loading for this database varies. In simple installations, you may populate this database with an export and import procedure. In more complex installations (and probably in future Oracle Clinical integration), you can populate the staging data directly from the CDM system using replication or triggers.

An alternative to using an extract and load to move that data from the clinical database to the staging tables is to use an Oracle function, such as views or snapshots, to make the data available to Oracle AERS for reconciliation.

Each table in the staging area has three components:

■ table_name_EXT - The table where external data is loaded using Clinical Extract Load.

■ table_name_OC - An optional view that dynamically extracts data from Oracle Clinical.

■ table_name - A view that UNION’s the _EXT and _OC, and presents the data to AERS Reconciliation.

This section describes the following staging tables:

■ RULE_ATTRIBUTES table

■ RULE_FIRING_MODES table

■ RCN_CASES table

■ RCN_PATIENT table

■ RCN_PATIENT_VITALS table

■ RCN_PT_AE_PROFILE table

■ RCN_PT_CAUSE_DEATH table

■ RCN_PT_DOSING table

RCN_CASES tableThis reconciliation table contains the case information for the patient.

PROJECT_DATA_IS_ OLD

The adverse event ONSET date is after the last visit date, and the final visit date is NULL. If this discrepancy exists, no further tests are made.

REVIEW_EVENT_ DETAILS

All reconciled cases have this discrepancy raised. In the description the events are sorted by Name and Date.

Table 12–9 RCN_CASES Table


CASE_ID Reconciled case ID number for the patient

STUDY_ID Enrolled study/protocol number.

PATIENT_ID The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial

Table 12–8 (Cont.) Reconciliation Rules

Rule Name Condition

Reconciliation


RCN_PATIENT tableThis reconciliation table contains the patient information.

RCN_PATIENT_VITALS tableThis reconciliation table contains vitals about the patient such as height and weight.

CENTER_ID Code corresponding to the Study Center where the patient was treated

Table 12–10 RCN_PATIENT Table



STUDY_ID Enrolled study/protocol number


INVEST_ID ID of the investigator for the case

PT_INITLS Patient's initials

PT_DOB Patient's birth date (if known)

PT_SEX_CD Patient's sex (field associated with a system code list). Valid values are: F (Female), M (Male), U (Unknown)

PT_RACE_CD Patient's race. Field can be associated with a user code list. Sample values are: ASN (Asian), BLK (Black), CAU (Caucasian), HIS (Hispanic); OTH (Other); UNK (Unknown)

SERIOUS_FLAG_COUNT

Indicates the total serious count

DEATH_DT Date of death

MOST_RECENT_VISIT_DT

Date of patient's last visit to doctor

FINAL_PATIENT_VISIT_DT

Date of final visit for the patient

PATIENT_CONTEXT Patient context text

CASE_RECON_STS Identifies reconciliation status of the case. Valid values are: N/A (case is spontaneous), REQ (Required - a new clinical case which has never been reconciled: status also occurs if the case is changed from spontaneous to clinical), RAN (reconciliation was either Required or Rerun Req. and it has been run), RRN (Rerun Req. - a reconciliation field has been changed)

MISSING_CASE_STS Identifies cases that are serious in the clinical data, but are not found in Oracle AERS

PROJECT_START_DATE Start date of the project (refers to the study start date)

DATA_UPLOAD_DT Data upload date

DATA_SRC_DB Data source database

Table 12–9 (Cont.) RCN_CASES Table


Reconciliation


RCN_PT_AE_PROFILE tableThis reconciliation table contains patient adverse event information.

Table 12–11 RCN_VITALS Table




CENTER_ID The code corresponding to the Study Center where the patient was treated

MEASUREMENT_DT Date measurements were taken

PT_WEIGHT Patient's weight

PT_WEIGHT_UNIT Unit of the patient's weight as entered. This field is associated with a system code list. Values are: LB, KG

PT_HEIGHT Patient's height

PT_HEIGHT_UNIT Unit of the patient's entered height. This field is associated with a system code list. Valid values are: Inches, CM

Table 12–12 RCN_PT_AE_PROFILE Table



STUDY_ID Enrolled study/protocol number.

CENTER_ID The code corresponding to the Study Center where the patient was treated

RCN_PT_SEQ_NBR Sequence number to uniquely identify a record

FROM_DT Onset date of the diagnosis or symptom

CO_VERBTM This is normally the same as the RPT_VERBTM but the company may update or override the reporter verbatim

EVENT_TID The value returned from the dictionary lookup

PREFERRED_EVENT_ TERM

Coding symbol that best matches the verbatim event phrase. If no match is found, the thesaurus manager must add a mapping

TO_DT End date of the event

OUTCOME_CD Indicates the outcome of the diagnosis or symptom. Values are: Resolved, Improved, Same, Worse, Death, Not Reported

SERIOUS_FLAG Indicates if the symptom or diagnosis fitting any of the severity criteria for reporting for the primary event is true, or if the symptom or diagnosis is associated with cancer, congenital anomaly, or overdose. Y/N/U

CASE_ID Unique identifier for a case. Includes site ID and the Manufacturer's Control Number

REPORTER_CAUSE_ TYPE

Indicates the causality, as judged by the reporter. This field is code listed in a user-modifiable code list. Sample values are: POS (possible), PRO (probable)

SEVERITY Indicates severity

Reconciliation


RCN_PT_CAUSE_DEATH tableThis reconciliation table contains patient cause of death.

RCN_PT_DOSING tableThis reconciliation table contains patient dosing information.

RELATEDNESS_CD Indicates an assessment as to whether the symptom or diagnosis is related to the suspect drug

Table 12–13 RCN_PT_CAUSE_DEATH Table





CAUSE_OF_DEATH_ CODE

The ICD code for the cause of death

CAUSE_OF_DEATH Text describing the cause of death

Table 12–14 RCN_PT_DOSING Table





PREFERRED_DRUG_ NAME

Preferred name

FROM_DT Start date of administration of the drug

DRUG_FORM Form in which the medication is administered. Field is associated with a user modifiable code list. Sample values are: INJ, SOLN, INH, SOLN, TABLET, CAPSULE, POWDER, SUPP, UNKNOWN

DRUG_TID Value returned from the dictionary lookup

DOSE A dosage of the suspect drug

DOSE_UNIT The units of dose

TO_DT End date of administration of the drug

ACTION_TAKEN Consequence of the event on the drug administration. Sample values are: S (Stopped), C (Continued), R (Reduced), I (Increased), U (Unknown), N (Not Applicable)

FREQUENCY Frequency of the concomitant or previous medication

Table 12–12 (Cont.) RCN_PT_AE_PROFILE Table


Clinical data extract file


Clinical data extract fileThe extract program extracts data from the clinical database. In most cases, the extract is the responsibility of the client.

The load program takes the extract file as input and loads it into the staging tables. The clinical extract load function is performed as an action against the uploaded file. If data for the patient (identified by Study ID, Center ID and Patient ID) already exists in the staging tables, the function replaces the data for that patient.

The Load program runs from the Oracle AERS Case Browse screen, which you can access by right-clicking on the file after it has been uploaded to Portal. It is implemented as a stored procedure. The stored procedure reads the file and makes the updates to the staging tables.

You can configure the layout of the Extract file. Oracle AERS can simultaneously support multiple layouts. The layout of the Extract file is defined in two files: the Format file and the Column Mapping file.

You can arbitrarily name the Extract, Format, and Column Mapping files, and place them in three separate, specified directories. The layout files and the Extract file are all UNIX ASCII text files.

Oracle security requires that users be given access to these directories. You can set up this security in Oracle by modifying the utl_file_dir parameter in the init.ora file. See the Oracle 8i documentation for details.

Format File: The Format file defines the position of the fields for each record type. The first line of the format file is a single number that specifies the number digits in the Record ID (this number should be "2"). The Format file has one line for each Record ID:

■ ID-n,n…

ID is the Record ID, a two-digit number.

n is a positive integer giving the number of bytes in each field.

Column Mapping File: As its name implies, the Column Mapping file maps fields in the Extract file to columns in the RCN tables. This file has one line for each record type:

■ ID-Table_Name-Column_Name1,Column_Name2…Column_NameN

ID is the Record ID. For each Record ID, all fields have to map to columns in one table.

Table_Name specifies the RCN table to which all columns for that Record ID must be mapped.

Column_Name1 - Column_NameN are the column names in the RCN table to which the corresponding fields map.

If a field does not map to a column, you may use the following syntax:

ROUTE The route of administration for the drug. Possible values: IA (Intraarterial), IM (Intramuscular), INH (Inhalation), IV (Intravenous), PO (Oral), SC (Subcutaneous), TOP (Topical)

RCN_DOSE_SEQ_NBR Reconciliation dose sequence number

Table 12–14 (Cont.) RCN_PT_DOSING Table




Column_Name1,,Column_Name3.

Coded field translationsOracle AERS provides a mechanism for translation coded values in the extract file to Oracle AERS terms or codes. Triggers on the staging tables translate the codes; you can modify these triggers. The general mechanism these triggers use for translating codes is to use the Oracle AERS code list tables. To use this mechanism, you must install translations of the codes used in the extract file. The Oracle AERS standard is to use the language code 'UPL' for these code list entries. The value for the CODE column is the Oracle AERS code, and the CODE_VALUE_TEXT is the extract file code.

Clinical extract load programClinical Extract Load is a stored procedure that can load data from a client-compiled extract file into the Staging Tables. Clients are responsible for assuring this extract file is loaded onto the server. You can execute the program by right-clicking the file name after it has been uploaded to the AERS Documents folder. For further details, refer to the Oracle Adverse Event Reporting System User’s Guide.

You must install two configuration files on the server, in the directory you want to use for loading the information. These configuration files describe the column and record layouts of the data you import from the extract file. Oracle AERS uses Oracle File I/O as an updating security measure for custom extract file loads. Configure Oracle File I/O to allow users to update the server directory specified for the extract files.

If you have company-specific data transformations to implement, you may install triggers on the RCN tables.



Configuring Case Bro

13
Configuring Case Browse
The Case Browse screen is configurable within certain limits (e.g. you are limited to three lines of summary data). The configuration is managed much the same way as Case Data Entry and Case Query. The various field attributes such as the screen label are managed in Field Attributes; each browse layout is managed as a mode.

This section contains the following subsections:

■ Overview

■ Adding or Updating a Custom Browse Configuration

■ Fields Available for Configuration

■ Out-of-the-Box Case Browse Configuration

OverviewThe Case Browse configuration is managed in four tables: Code Lists, Data Entry Modes, Field Attributes, and Field Modes.

ModesEach Case Browse screen configuration is defined as a Data Entry Mode, with specific fields and field modes. The Case Browse mode entry is fairly simple, consisting of an ID and Description:

Field AttributesThe Case Browse screen configuration is managed in the Field Attributes table and is configured using the Workflow Configuration application. The Case Browse screen uses a subset of the Field Attributes as defined in the following table:

Attributes Req? Description

DE_MODE Y The unique ID of the Case Browse Mode. We recommend prefixing the mode name with a unique string, such as BRW-, to readily differentiate Browse modes from data entry modes. The name must also correspond to the Code value in the Browse Modes Code List

MODE_DESCRIPTION N This is the free text mode description. It is not used by AERS but can be useful for documenting your entry.

wse 13-1

Overview

Relevant Field ModesEach configurable browse screen layout corresponds to a Data Entry Mode (aka workflow task). Individual fields are surfaced and positioned using the Field Modes block as follows:


FORM_NAME Y The Oracle Forms Form Name. Must be B_CASEBR

WINDOW_NAME Y The AERS Window Name. Must be CASE_BROWSE_WDW.

BLOCK_NAME Y The Forms Block Name. Must be QTEMP

ITEM_NAME Y The Forms Item Name. You must use one of the 66 pre-defined items. You cannot change the item name for the Case Browse Screen.

TABLE_NAME The table name from which the data is derived. This table must be accessible to AERS and included in the Query Join Tables.

FIELD_NAME The column name in the table from which the data is derived. The Field Name may be left blank if the value is being derived from the SQL Statement in the DIC_QUERY_TEXT column.

SCREEN_LABEL Y The field label that displays on the Case Browse Screen.

FIELD_LABEL Y The field label used internally.

CODE_LIST The Code List Name if the field is being decoded against a code list on display.

VIEW_VALUE_FLAG If the field is being decoded against a code list to display the value, this field should be set to Y

SUB_QUERY_TEXT Used to specify any additional selection criteria for fetching the data as part of the SQL WHERE Clause (such as limiting the value to a primary event term). This field must be specified for any child record (you must return a single unique record for each case). This field can also be used to sort the data.

DIC_QUERY_TEXT Used to augment the processing of the data item as part of the SQL SELECT statement, for example, to DECODE the values.


FORM_NAME Y The Oracle Forms Form Name. Must be B_CASEBR

BLOCK_NAME Y The AERS Window Name. Must be CASE_BROWSE_WDW.

ITEM_NAME Y The Forms Block Name. Must be QTEMP

DE_MODE Y The Data Entry Mode name for the configurable browse format

HIDDEN_FLAG Y If the field is visible in the browse view, this flag should be set to N. If the field is not visible on the Browse mode, then this flag should be Y

X_POSITION The X position of the field within the Browse Mode

Y_POSITION The Y position of the field within the Browse Mode. The values are 59, 70, 81 for rows one, two and three respectively.

FIELD_HEIGHT The field height of the field within the Browse Mode. This value must be 11.

FIELD_WIDTH The field width of the field within the Browse Mode


Adding or Updating a Custom Browse Configuration

Adding or Updating a Custom Browse ConfigurationTo add or update a Case Browse Configuration:

1. Create a new entry in the BROWSE_MODES codelist corresponding to the new mode, or update the code list details to reflect the desired change. Complete the following details:

■ Code: Name of the Case Browse Mode (e.g. BRW-<new mode>). This value must exactly match the name of the mode in the Data Entry Modes and Field Modes tables.

■ Code Value Text: The name of the Browse Mode that displays in the Drop down menu on Case Browse Window.

2. Create the Data Entry Mode for the new Browse Mode. You can use the New Mode feature within Field Attributes to create the new mode, or you can create it manually. We recommend using the New Flow function.

a. Launch the Workflow Configuration form from the AERS Home Page.

b. Select Create New Flow from Actions menu.

c. Select an existing Case Browse Mode to copy.

d. Enter the name of the new Browse mode from Step 1 and an optional description.

e. Ensure that no other information is selected or entered, and press OK to create the new Browse Mode.

This approach generates a copy of the Field Modes and a corresponding entry in the Role Attributes table. If you choose to create the mode entry manually, you need to also do these steps manually.

3. Create or update Field Mode entries. A Field Mode needs to be created for each field that appears in a given Case Browse mode. The easiest way to do this is to use the Create New Flow option is Step 2. If you created the mode manually, you need to insert a new record in the Modes block for each field you want to display in the mode. Adjust the information as follows:

■ Date Entry Mode: The Data Entry Mode name for the configurable browse format.

■ Hidden: If the field is visible in the browse view, this flag should be set to N. If the field is not visible on the Browse mode, then this flag should be Y.

■ Y: The Y position of the field within the Browse Mode. The values are 59, 70, 81 for rows one, two and three respectively.

■ X: The X position of the field within the Browse Mode.

■ Width: The field width of the field within the Browse Mode.

■ Ht: The field height of the field within the Browse Mode. This value must be 11.

4. Update the Field Attributes to configure any previously unused Browse fields or update existing uses. See the Table below for the complete list of Note: Any given field must have the same Field Attributes in all modes. If you are using the same field in different ways, you must configure one of the Case Browse flex fields to accommodate the differences.

5. Recompile the Case Browse triggers. The data are displayed in the Case Browse screen based on a database triggers on the QTEMP table. The triggers are

Configuring Case Browse 13-3

Fields Available for Configuration

responsible for transforming the summary data according to the Field Attributes you configure as part of step 4. Anytime you modify the Field Attributes, you must recompile the triggers for the changes to take affect in Case Browse.

a. Launch the Workflow Configuration form from the AERS Home Page.

b. Select Rebuild Browse Config from Actions menu

c. Exit Workflow Configuration

6. Configure the Default Case Browse for each user using the User administration screen on the AERS Administration Console.

Fields Available for ConfigurationThe following Field Attributes items are available for Case Browse Configuration:

Note: You should only perform this step when users are off the system.

ITEM_NAME TABLE_NAME FIELD_NAME SCREEN_LABEL

ACIS_FLAGS AE_CASES ACIS

CASE_ID AE_CASES CASE_ID Case ID

CASE_OWNER_USR_GRP_ID

AE_CASES CASE_OWNER_USR_GRP_ID

Owning Group

CASE_OWNING_USER AE_CASES CASE_OWNING_USER Owning User

CASE_STS AE_CASES CASE_STS Status

CASE_UPDATE_DT AE_CASES CASE_UPDATE_DT Update Date

CASE_UPDATE_USER_ID

AE_CASES CASE_UPDATE_USER_ID

Update User

CENTER_ID AE_CASES CENTER_ID Center

CORE_UNEXPECTED_FLAG

AE_CASES CORE_UNEXPECTED_FLAG

Core

CO_ASSMNT_RELTD_CD

AE_CASES CO_ASSMNT_RELTD_CD

Co Related

DRUG_FORM AE_CASES DRUG_FORM Drug Form

EV_OCC_COUNTRY_CD AE_CASES EV_OCC_COUNTRY_CD Country

EV_ONSET_DATE AE_CASES EV_ONSET_DT Onset Date

HISTORICAL_FLAG AE_CASES HISTORICAL_FLAG Historical Flag

PATIENT_ID AE_CASES PATIENT_ID Patient

PRIORITY AE_CASES CASE_PRIORITY Case Priority

PROCESS_FLAG AE_CASES PROCESS_FLAG Process Flag

PROD_CD AE_CASES PROD_CD Product Code

PROJECT_DRUG_NAME AE_CASES PROJECT_DRUG_NAME Drug Project

PT_AGE AE_CASES Age

PT_RACE AE_CASES PT_RACE_CD Race


Fields Available for Configuration

PT_SEX AE_CASES PT_SEX_CD Sex

RECONCILIATION_STS AE_CASES RECONCILIATION_STS Reconciliation

REPORTER_CAUSE_TYPE

AE_CASES REPORTER_CAUSE_TYPE

Rep Causality

SERIOUS_FLAG AE_CASES Serious

STUDY_ID AE_CASES STUDY_ID Study

UNEXPECTED_IN_ORIG_COUNTRY

AE_CASES UNEXPECTED_IN_ORIG_COUNTRY

Local

US_UNEXPECTED_FLAG AE_CASES US_UNEXPECTED_FLAG

US

VALIDATION_REQD_FLAG

AE_CASES VALIDATION_REQD_FLAG

Validation Req

CO_VERBTM AE_EVENTS CO_VERBTM Event

OTHER_CASE_ID AE_OTH_CASE_REFS OTHER_CASE_ID Other Case ID

NEXT_REPORT_DUE_DATE

AE_REPORTABILITY NEXT_DUE_DATE Report Due Date

NEXT_REPORT_DUE_FORM

AE_REPORTABILITY NEXT_REPORT_FORM Report Form

COMPLAINT_CODE AE_SUSPECT_DRUGS COMPLAINT_CODE Complaint Code

DRUG_NAME AE_SUSPECT_DRUGS DRUG_NAME Product

INITIAL_FOLW_UP EC_CONTACT_LOG Init/Follow-up

INITIAL_RECEIVE_DATE EC_CONTACT_LOG RECEIVE_DATE Init Received Date

RECEIVED_DATE EC_CONTACT_LOG Latest Followup

OPEN_INVESTIGATIONS

PC_INVESTIGATIONS Open Investigations

PENDING_PRODUCT_RETURNS

PC_RETURNS Pending Returns

OPEN_CORRECTIVE_ACTIONS

TE_CORRECTIVE_ACTIONS

Open Corr Actions

RPT_SOURCE_TYPE TE_PREFERRED_SOURCE PREFERRED_SOURCE Source

NEXT_TASK VW_NEXT_TASK NEXT_TASK Next Task

NEXT_TASK_DUE VW_NEXT_TASK NEXT_TASK_DUE Due Date

ITEM01 Item 01

ITEM02 Item 02

ITEM03 Item 03

ITEM04 Item 04

ITEM05 Item 05

ITEM06 Item 06

ITEM07 Item 07

ITEM08 Item 08

ITEM09 Item 09



Out-of-the-Box Case Browse Configuration

Out-of-the-Box Case Browse ConfigurationThere are two default case browse configurations included with AERS: Default and Product Complaint. These can be used as models for further configuration. You can use the following query to examine to active fields in the Case Browse configuration:

select dm.de_mode, dm.mode_description,

fa.item_name, fa.table_name, fa.field_name,

fa.dic_query_text, fa.sub_query_text,

fm.x_position, fm.y_position, fm.field_width

from field_attributes fa, field_modes fm, data_entry_modes dm

where fa.form_name = fm.form_name

and fa.block_name = fm.block_name

and fa.item_name = fm.item_name

and fm.de_mode = dm.de_mode

and fa.form_name = 'B_CASEBR'

and fm.y_position <> 0

order by dm.de_mode, fm.y_position, fm.x_position;

ITEM10 Item 10

ITEM11 Item 11

ITEM12 Item 12

ITEM13 Item 13

ITEM14 Item 14

ITEM15 Item 15

ITEM16 Item 16

ITEM17 Item 17

ITEM18 Item 18

ITEM19 Item 19

ITEM20 Item 20

PICKED_FLAG Picked

SORT_SEQ_NBR Seq#

Field Attributes

Field Modes

Item Name Table NameField Name Dic Query Text

Sub Query Text X Pos Y Pos Field Wdth

BRW - DEFAULT: Default modes




SORT_SEQ_NBR

162 59 30

NEXT_TASK VW_NEXT_TASK

NEXT_TASK

192 59 75

CASE_ID AE_CASES CASE_ID 267 59 77

STUDY_ID AE_CASES STUDY_ID 344 59 61

CASE_STS AE_CASES CASE_STS 405 59 76

SERIOUS_FLAG

AE_CASES decode(DIED_FLAG,'Y','DEATH',decode(LF_THREAT_FLAG,'Y', 'LIFETHREAT',decode(SERIOUS_FLAG,'Y','SERIOUS','N','NOT-SERIOUS',NULL)))

481 59 63

PROD_CD AE_CASES PROD_CD 543 59 98

PICKED_FLAG 162 70 30

NEXT_TASK_DUE

VW_NEXT_TASK

NEXT_TASK_DUE

192 70 75

EV_OCC_ COUNTRY_CD

AE_CASES EV_OCC_COUNTRY_ CD

267 70 77

CENTER_ID AE_CASES CENTER_ID

344 70 61

INITIAL_RECEIVE_ DATE

EC_CONTACT_LOG

RECEIVE_DATE

order by CONTACT_SEQ_NBR

405 70 76


AE_CASES CORE_UNEXPECTED_ FLAG

481 70 32

US_UNEXPECTED_ FLAG

AE_CASES US_ UNEXPECTED_ FLAG

513 70 31

CO_VERBTM AE_EVENTS CO_VERBTM

and DISPLAY_NBR = 1

543 70 98

Field Attributes

Field Modes





ACIS_FLAGS AE_CASES decode(ADVERSE_EVENT_FLAG, 'Y','A') || decode( PRODUCT_COMPLAINT_FLAG,'Y', 'C') || decode(MEDICAL_ INQUIRY_FLAG, 'Y','I') || decode( SERVICE_COMPLAINT_FLAG,'Y','S')

162 81 30

PRIORITY AE_CASES CASE_PRIORITY

192 81 75

RPT_SOURCE_ TYPE

TE_PREFERRED_ SOURCE

PREFERRED_ SOURCE

267 81 77

PATIENT_ID AE_CASES PATIENT_ID

344 81 61

RECEIVED_DATE

EC_CONTACT_LOG

max(RECEIVE_DATE)

405 81 76


AE_CASES REPORTER_CAUSE_ TYPE

481 81 63

EV_ONSET_DATE

AE_CASES EV_ONSET_DT

543 81 98

BRW-PC: Complaints

SORT_SEQ_NBR

162 59 30

NEXT_TASK VW_NEXT_TASK

NEXT_TASK

192 59 75

CASE_ID AE_CASES CASE_ID 267 59 77

STUDY_ID AE_CASES STUDY_ID 344 59 61

OPEN_CORRECTIVE_ ACTIONS

TE_CORRECTIVE_ ACTIONS

decode(count(*),0,'N','Y')

and DATE_COMPLETED is NULL

344 59 76

CASE_STS AE_CASES CASE_STS 420 59 76

Field Attributes

Field Modes





SERIOUS_FLAG

AE_CASES decode(DIED_FLAG,'Y','DEATH', decode(LF_THREAT_FLAG,'Y', 'LIFE-THREAT',decode( SERIOUS_FLAG,'Y','SERIOUS','N','NOT-SERIOUS',NULL)))

481 59 63

PROD_CD AE_CASES PROD_CD 496 59 145

PICKED_FLAG 162 70 30

NEXT_TASK_DUE

VW_NEXT_TASK

NEXT_TASK_DUE

192 70 75

EV_OCC_COUNTRY_ CD

AE_CASES EV_OCC_COUNTRY_ CD

267 70 77

CENTER_ID AE_CASES CENTER_ID

344 70 61

OPEN_ INVESTIGATIONS

PC_ INVESTIGATIONS

decode(count(*),0,'N','Y')

and DATE_COMPLETED is NULL

344 70 76

INITIAL_RECEIVE_ DATE

EC_CONTACT_LOG

RECEIVE_DATE

order by CONTACT_SEQ_NBR

420 70 76


AE_CASES CORE_UNEXPECTED_FLAG

481 70 32

COMPLAINT_CODE

AE_SUSPECT_ DRUGS

COMPLAINT_CODE

and DISPLAY_NBR = 1

496 70 145

US_UNEXPECTED_ FLAG

AE_CASES US_UNEXPECTED_ FLAG

513 70 31

CO_VERBTM AE_EVENTS CO_VERBTM

and DISPLAY_NBR = 1

543 70 98

Field Attributes

Field Modes





ACIS_FLAGS AE_CASES decode(ADVERSE_EVENT_FLAG,'Y','A') || decode(PRODUCT_ COMPLAINT_FLAG,'Y','C') || decode(MEDICAL_INQUIRY_FLAG,'Y','I') || decode(SERVICE_ COMPLAINT_FLAG,'Y','S')

162 81 30

PRIORITY AE_CASES CASE_PRIORITY

192 81 75

RPT_SOURCE_ TYPE

TE_PREFERRED_ SOURCE

PREFERRED_ SOURCE

267 81 77

CASE_OWNING_ USER

AE_CASES CASE_OWNING_ USER

267 81 77

PATIENT_ID AE_CASES PATIENT_ID

344 81 61

PENDING_PRODUCT_ RETURNS

PC_RETURNS decode(count(*),0,'N','Y')

and DATE_RETURNED is NULL

344 81 76

RECEIVED_DATE

EC_CONTACT_LOG

max(RECEIVE_DATE)

420 81 76


AE_CASES REPORTER_CAUSE_ TYPE

481 81 63

EV_ONSET_DATE

AE_CASES EV_ONSET_DT

496 81 145

Field Attributes

Field Modes




Case Data Query 14-1

14 Case Data Query

The Case Data Query subsystem is completely configurable. The fundamental structure of query consists of a set of 30 generic Oracle Forms Blocks, each with 40 generic Items. The default query configuration maps a set of the query blocks onto the standard case data, and maps the query items to the fields that appear on the Data Entry screens. This configuration results in an approachable query-by-example interface for query. In addition to this query-to-data entry mapping, the default query configuration includes a Quick Query screen that is a collection of frequently queried fields. Query also includes mappings to supporting views and external tables, such as the Oracle Clinical Studies table.

Through configuration you can:

■ Remove fields from the default configuration.

■ Modify query field labels.

■ Change codelist assignments to query fields.

■ Relocate existing query fields.

■ Add new query screens and query fields to existing screens that support querying on other Oracle AERS tables (e.g. the audit tables), external systems (e.g. Manufacturing or Clinical Data Management), or new views that you have added to the Oracle AERS environment to support your business processes.

Oracle AERS includes a SQL Generator which takes the configuration elements and builds a SQL statement that the system then executes against the database. This SQL Generator is fully validated.

You can also create and save standard queries, then make these queries available to users.

Query configurationThis section describes the two principal query configuration tasks: Modifying existing query configuration and Adding new query fields.

Modifying existing query configurationYou can quickly and easily modify the visual aspects of query, such as field labels, visible fields, and codelists. Oracle AERS stores the configurable aspects of Query in the Field Attributes and Window Attributes tables, as the system does for the configurable aspects of Data Entry.

Query configuration


Table 14–1 Configuring Query Fields


FORM_NAME N Name of form (QUERY)

BLOCK_NAME N Name of the block on the form (QRYBLOCKnn)

ITEM_NAME N Field on the block/form (ITEMnn)

WINDOW_NAME

N Name of the window (QRYBLOCKnn_WDW)

FIELD_TYPE N Type of field in the Field Attributes Table (FLD)

TABLE_NAME Y Table name

FIELD_NAME Y Field name

DATA_TYPE Y Defines the data type of the field. Possible values include: CHR (Character), DAT (Date), PDT (Partial Date), BLN (Boolean), LNG (Long), LST (List), and DIC (Dictionary Term)

HELP_CONTEXT_ID

Y Tag to support the help facility. Use this number when customizing your field help.

RELTD_ITEM_NAME

Y Stores the base table and item name if the current item is a mirror item. Otherwise, this field is Null

Table 14–2 Configuring Query Code Lists


CODE_LIST Y Code list, used to populate record group

CODE_LST_SOFT_VAL_FLAG

Y Is validation soft (Y) or hard (N) for code listed fields? Note: This does not apply to the Lists fields in the Quick Query screen (Case List, Study List, Country List, Patient List, Sub Drug List, Proj Drug List, and Prod Code List). For those fields, the validation is always hard

Table 14–3 Configuring Query Appearance


DEFAULT_VALUE Y Default value used when record is inserted

FIELD_LABEL Y Label of field used in reports and audit functions

SCREEN_LABEL Y Label of field on the screen

FORCE_CASE_FLAG Y Forces the case of field content (i.e., force uppercase). Values: U (Uppercase), L (Lowercase), and M (Mixed Case)

X_POSITION Y X Position of fields on the data entry and query screens (pixels from top right corner). This field is only updatable for fields on the Query screens in Oracle AERS 4.5.

Y_POSITION Y Y Position of fields on the data entry and query screens (pixels from top right corner). This field is only updatable for fields on the Query screens in Oracle AERS 4.5.

FIELD_HEIGHT Y Field Height of fields on the data entry and query screens (in pixels). This field is only updatable for fields on the Query screens in Oracle AERS 4.5.

Query configuration


FIELD_WIDTH Y Field Width of fields on the data entry and query screens (in pixels). This field is only updatable for fields on the Query screens in Oracle AERS 4.5.

Table 14–4 Configuring Query Help Text


HELP_TEXT Y Custom help text for field. This feature has not been fully implemented in Oracle AERS 4.5.

Table 14–5 Configuring Query Dictionary Fields


MAPPING_ID N Sequence ID for query mapping

DIC_QUERY_TEXT Y Additional query text required for dictionary field with dictionary switches enabled

SUB_QUERY_TEXT Y Additional query criteria that is added as a nested sub-query when querying on the field.

Table 14–6 Query Customization


CUSTOM_RESTR_TEXT Y Text describing customization restrictions

CUSTOM_COMMENTS_TEXT

Y Text describing customization

CUSTOM_PERMSN_TYPE N Custom permission type S (System), C (Customer may modify)

Table 14–7 Query Creation and Modification


CREATE_DT S Creation date

CREATE_SITE_ID S Creation site

CREATE_USER_ID S Creation user

UPDATE_DT S Last modified date

UPDATE_SITE_ID S Modifying site

CREATE_USER_ID S Modifying user

Table 14–8 Query Window Configuration


CURRENT_WDW N Current window (QRYBLOCKnn_WDW).

FORM_NAME N Form Name for the window (QUERY)

WDW_LABEL Y Label that displays in the window title bar

Table 14–3 (Cont.) Configuring Query Appearance


Query configuration


To modify the Query screens using the Field Attributes form:

1. From the Query subsystem place the cursor in the field you wish to modify and select Help=>FAT Configuration.


2. Configure the screens and fields by performing one or more of the following tasks:

■ To hide a field, enter Y in the Hidden field on the lower block of the screen.

■ To change a Field or Screen Label, click once in the field and enter the new label in the Screen Label and Field label.

■ To change a codelist associated with the field, double-click in the Code List field and select the name of the codelist associated with the field. If you want to validate literal values that the users enter as query criteria, set the CODE_LIST_SOFT_VAL_FLAG to N. When this value is N, users can enter literal values that exist in the codelist.

■ To force the case for a query field enter U for Upper Case, M for Mixed Case, or L for Lower Case, in the Force Case field.

■ To move a field within a screen, update the coordinates by changing the values for the X-Position, Y-Position, Field Width, and Height (in pixels).

3. Click the Save button or press the F10 key to save your changes.

Adding new query fieldsWhen adding a new field to query, you must add it to the appropriate query screens and define the infrastructure necessary for the SQL generator to create SQL statements that utilize the field appropriately. Failure to correctly configure the infrastructure leads to erroneous query results.

Creating support viewsIn many circumstances, you add specific views (or tables) to the Oracle AERS application environment that your users need to include in case data queries. For example, you may want to allow users to include manufacturing details in their case data queries based upon a link from the Lot Number in the Case Data into your Manufacturing system. In order to accommodate this type of query, you can construct a view that transforms the data from the manufacturing system to a usable structure in Oracle AERS, then link that view with the external system through a standard database link.

Once you create the view, you must introduce the join criteria from Oracle AERS to the external view.

HELP_CONTEXT_ID N Tag to support the help facility

HELP_TEXT Y Modifying site

Note: If you link to an external system, you must create a public link and grant READ access to that link to the ENUSER role.

Table 14–8 (Cont.) Query Window Configuration


Query configuration


Adding the Query Table JoinThe Query Table Join specifies the join criteria between tables. Because most queries involve joins with the AE_CASES table, AE_CASES is the primary join table. However, if you are joining based upon other key data (such as Lot Number), your query join should be between the Oracle AERS table that stores the join value and the external table or view.

To modify global field attributes using Field Attributes tool:

1. Launch the Oracle AERS Field Attributes Form by double-clicking the FLD_ATTR.FMX executable in the Oracle AERS folder.

The Field Attributes window displays.

2. Click the Define Query Joins button.

The Query Table Joins screen displays.

3. Add the following fields:

■ Table Name: The name of your table or view that contains the data field on which you are querying.

■ Parent Table Name: The name of the table in Oracle AERS to which you join the table.

■ Join Condition: The WHERE clause conditions that you must add to the generated query in order to include the table. Note that your criteria can include multiple conditions and other valid join criteria (such as the outer join criteria specified in the above example).

4. Click the Save button, or press the F10 key, to save changes.


Adding a new field to the query screensOnce you add the Query Table Join, you must add the field (or fields) to one or more of the query windows.

To add a new query field:

1. Navigate to the Query subsystem.

2. Select Help=>FAT Configuration.


3. Click the Insert Record button.

4. Enter values in the following fields:

■ Table Name: The name of the table or view containing the column.

■ Field Name: The name of the column in the table that is queried.

■ Screen Label: The name of the field that appears on the screen.

Note: If the FLD_ATTR.FMX form is not stored on your hard disk, you must run the Oracle AERS Admin Setup program from the Oracle AERS installation CD. This program installs the forms you need to perform screen and field configuration.

Adding custom queries


■ Field Label: The name of the field that appears in the Case Detail report and the Query Summary.

■ Others as defined in the Field Attributes table above.

5. Click the Save button, or press the F10 key, to save the newly created field.

Adding an Exclude Flag to a new blockThe Exclude Flag is a special query field that generates a NOT IN clause in the SQL statement. It allows you to identify cases that have no matching records to the criteria entered on that block.

To add an Exclude Flag:

1. Follow steps 1-5 from "Adding a new field to the query screens" on page 14-5.

2. Right-click on the screen canvas and select Add Exclude Flag from the pop-up menu.

3. Enter the following fields:

■ Table Name: The name of the table or view containing the column. The table name is the only field that needs to be completed here are the Exclude criteria apply to records within that table.

■ Field Name: Leave this field blank.

■ Screen Label/Field Label: The field name that appears on the screen or reports.

4. Click the Save button, or press the F10 key, to save the newly created field.

Adding custom queriesOnce you have constructed a query infrastructure, you can build a library of standard queries that your users can run. These queries are accessible from the Case Browse (Inbox) subsystem and, for users than can access Query, from the Case Query subsystem as well.

To add saved queries:

1. Log on to Oracle AERS as SUPERUSER or any other non-user account.

2. Open the Query subsystem by clicking the Query button or selecting Cases=>Query Cases.

The Query Subsystem opens.

3. Enter the criteria for the query.

4. Click the Save button, or press the F10 key, to save the query.

The Save Query As… dialog box appears.

5. Enter the Query Name and Description, and mark the Query as Public so users can run the query. Saved queries that ship with Oracle AERS contain a dollar symbol ($) that precedes the name. You should reserve this standard for Oracle queries.

Caution: DO NOT change the values of the Window Name, Block Name and Item Name. These are not configurable.



6. Click OK.

Once you create the query, users can add it to their Favorites, or it can become part of the Inbox criteria.

Managing user favorites using the Administrator ConsoleTo manage user favorites from the Administrator Console:


2. Select the User Profile tab, then highlight the appropriate user from the Navigator panel.

The corresponding fields auto-populate to reflect the current user. In the bottom right corner of the screen is the subsection Inbox/Favorites.

3. In the Query Name field, enter the name of the Saved Query.

If the Inbox? flag is selected, the Saved Query executes as part of the user’s Inbox. If it is not selected, the Saved Query appears in the user’s Favorites folder.



E2B Configuration 15-1

15 E2B Configuration

This chapter contains details on configuring the E2B import and export rules as well as configuring E2B Automation. The detailed information on the E2B configuration is contained in the E2B chapter of the Oracle AERS Reports TRM. The TRM is updated more frequently than the Administration Guide, so please refer to the TRM for the latest details concerning the configurable options for the E2B.

The approach to E2B in Oracle AERS is to develop a common set of functionality to manage all aspects of the electronic interchange process. As such, this chapter includes the implementation of E2B Export (creation of E2B files for transmission), E2B Import (creating new AERS cases from inbound E2B messages from trading partners such as regulators, partners, or other manufacturers), the E2B Acknowledgement functionality, and E2B Automation (support for the automated interchange of ICSRs between established trading partners).

As with other Oracle AERS features, an emphasis has been placed on providing maximum flexibility and configurability to E2B to accommodate not only differences in requirements between regulators, but differences in coding standards between trading partners.

There are several areas that manage the configuration details for E2B:

Run-Time Parameters: Unlike many reports, the run-time parameters for E2B do not radically alter the contents of the output, except to determine the receiver of the E2B submission and to control the transmission of a nullification report.

E2B Receivers: The E2B Receivers table controls the specific details about the trading partners to whom you are sending E2B files. This includes substantive details such as the dtd version, as well as more subtle features, such as whether decimal points are supported for input.

E2B Senders (a.k.a. E2B Import Rules): The E2B Import Rules table controls the details about the trading partners that are ending you E2B files. The configurable options control the way in which incoming files are handled.

E2B Mapping: Oracle AERS uses a combination of tables to control specific coding and decoding of E2B fields. The most critical table in this is the E2B Mapping table, however, this table should not be changed by customers. Beyond this, there are several standard configuration options such as E2B language decode in codelists that are used.

Run-Time ParametersThe E2B Export is handled with the same user interface as other Oracle AERS reports. When creating an E2B file for review or submission, run-time parameters are used to collect specific details about the export.

Export processing


The default details about the sender (your company) are stored as run-time parameters. To update the default values, and optionally, hide these from users, please review the Report Configuration chapter.

Export processingThe E2B export process executes as a standard AERS individual case submission report. A user executes the E2B export process from the AERS Reporting subsystem. The resulting output is an SGML- or XML-format file that is stored in a BLOB as an AERS document. The export process also creates AERS report output. The printed output is a record of the job and contains a log of any resulting errors.

The E2B_RECEIVERS table controls the receiver-specific options of the export. The table is keyed by the AGENCY report parameter. The options controlled by this table were specifically designed to address the differences between the FDA and EMEA implementations of the E2B.

Configuring E2B Export (submissions)You capture specific details about the receiver (such as contact information) as well as file format options in the E2B Receivers table. Please refer to the following sections for the detailed descriptions of the various options and their implications on E2B output. Further details can be found in the E2B chapter of the Reports TRM.

To define a new receiver or update and existing one:

1. Select the E2B Receivers tab from the Global Maintenance subsystem.

The E2B Receivers screen displays.

2. Click the Add Record button or select Edit=>Add Record to add a new trading partner, or scroll to an existing entry to update.

3. Key in all fields as described in the following sections.

4. Click the Save button, or select File=>Save, to save your changes.

The Receiver is saved to the database.

E2B_RECEVIERS TableThe E2B Receivers table includes the following columns:

Flag Explanation Action

E2B_VERSION Sets the default DTD version used for this export. It can be overridden by the DTD_VERSION parameter

INCLUDE_ASSESSMENT

If ‘Y’, the event to drug assessment of causality is included in the Export according to the rules in the field by field section of this document.

If ‘N’, no event to drug assessment data is included in the export.

Export processing


SEND_MEDDRA_CODES

The EMEA has adopted the standard of transmitting MedDRA codes for controlled terminology rather than text terms. Because this is not universally adopted, this option allows customers to control what is transmitted based upon the requirements outlined by the receiver.

If ‘Y’, the dictionary code numbers are sent for MedDRA encoded fields rather than the text. For unmapped terms, the text is sent.

If ‘N’, the text term is sent.

INCLUDE_VERSION AERS increments the case version number based upon workflow events as specified in the Case Version view specification. As there is no clear criteria from regulators on what constitutes a case version, this data element can be omitted using this option.

If ‘Y’ the case version is included.

If ‘N’, the case version field is left blank.

USE_LONG_CASEID The EMEA requires the safetyreportid be a concatenation of three data values, separated by dashes:

<COUNTRY>-<COMPANY>-<CASE-ID>

If ‘Y’ AERS first looks to see if the existing case ID is a “global Case ID,” then it checks the Other Case ID for a global case ID entry. If neither of these conditions is met, then AERS creates the safetyreportid by concatenating

SENDERORGCOUNTRY

SENDERID

(AERS) CASE_ID

separated by dashes.

If ‘N’ the AERS case-id only is sent.

SEND_PT_VERSION The EMEA does not want the reactionmeddraversionpt tag included in the file.

If ‘Y’, the reactionmeddraversionpt tag is included in the output.

If ‘N’, the tag is not included.

EDI_HEADER The EMEA and FDA both require receiver-specific data to appear before the ichicsr tag.

If not null, the header is placed at the start of the file. No separators are added between the header and the start of the XML data.

EDI_TRAILER The EDIFact gateway requires a message trailer. No trailer is needed for EMEA output.

If not null, the trailer is added at the end of the file. No separators are added between the normal end of file and the trailer.


Export processing


INCLUDE_EDIFACT_ENVELOPE

This flag modifies the output to meet EDIFact/FDA requirements.

This option works in conjunction with the EDI_HEADER and TRAILER.

If ‘Y’,

The file type suffix is set to.edi instead of the usual.xml.

EFIFACT specific data is added to the EDI header and trailer. Specifically,

To_char(sysdate,’yymmdd:hh24:mi) || ‘+’ || queue-id ||’’’’

Is appended to the header and

Queue_id || ‘’’’ is appended to the trailer

DB_SERVER_OUTPUT_DIRECTORY

This option is used to place a file, where it is be to be picked up and transmitted automatically by the gateway.

The file is written in the file system of the database server.

If not null, when the E2B export is run in submission mode, the export places a copy of the export output file in this directory. The file name is the same internal file name generated by Portal and is unique. AERS uses the UTL_FILE package to write the file. The directory must be included in the utl_file_dir INIT.ORA parameter.

SUPPRESS_PARTIAL_ DATES

The EMEA has identified a number of dates that must be full dates (year, month, and day). This feature suppresses those fields if they are partial dates.

If ’Y’ AERS suppresses any partial date from appearing in the output if the corresponding field is defined as a full date in the E2B Mapping Table (RULE_PARM1 = DATE and RULE_PARM2 = FULL).

SUPPRESS_ NON_NUMERIC_VALUES

In some cases, AERS may accept non-numeric data where a trading partner is expecting only numeric data. This option suppresses this.

If ’Y’ AERS suppresses any non-numeric value from a field that is defined as numeric in the E2B_MAPPING table (RULE_PARM1 = NUMERIC).

SUPPRESS_NON_MEDDRA_TERMS

The EMEA has stipulated that only valid MedDRA LLTs should be transmitted in the E2B files. This option suppresses the term if it not mapped to MedDRA and the text is to be sent.

If ’Y’ LLTs that are not mapped to MedDRA terms are not included in the output. Note: Some of these unmapped terms are presented in other, related comments fields if the corresponding Convert to Free Text option is enabled for the receiver.

SUPPRESS_LONG_DATA

The E2B specifications include field lengths and some trading partners enforce these lengths on import. This option truncates these fields.

If ’Y’ and the corresponding field in longer than the length defined in the E2B_MAPPING table, the string is truncated. Some of these values are continued into free text fields if the corresponding Convert To Free Text option is true for the receiver.

SUPPRESS_DECIMAL_VALUES

The FDA, and potentially other trading partners do not accept numeric data with decimal points. This option truncates numeric data for these receivers.

If ’Y’ and the corresponding numeric field includes a decimal point, the value is truncated before being output.


Export processing


FREE_TEXT_LANG_CD Defines the language code used to decode the text strings for a receiver.

DRUGFORM_TO_DRUGINFO

If a drug form is not in the published list, it is output into the drug info field.

If ’Y’ and there is no E2B decode for the Drug Form it is suppressed from the drug form field <drugdosageform> and included in the Drug Info tag instead <drugadditional>

DRUGFORM_TO_DOSETEXT

If a drug form is not in the published list, it is output into the dose text field.

If ’Y’ and there is no E2B decode for the Drug Form it is suppressed from the drug form field <drugdosageform> and included in the Dosage Text tag instead <drugdosagetext>

DRUG_ FORM_LABEL The label that is prefixed to the free text drug form if it is converted to a different field.

This value is prefixed to the Drug Form is it is output to a free text field because of the DRUGFORM_TO_DOSETEXT or DRUGFORM_TO_DRUGINFO options.

DOSEUNIT_TO_DRUGINFO

If a dose unit is not in the published list, it is output into the drug info field.

If ’Y’ and there is no E2B decode for the dose unit it is suppressed from the dose unit field <drugstructuredosageunit> and included in the Drug Info tag instead <drugadditional>

DOSEUNIT_TO_DOSETEXT

If a dose unit is not in the published list, it is output into the dose text field.

If ’Y’ and there is no E2B decode for the dose unit it is suppressed from the dose unit field <drugstructuredosageunit> and included in the Dosage Text tag instead <drugdosagetext>

DOSE_UNIT_LABEL The label that is prefixed to the free text dose unit if it is converted to a different field.

This value is prefixed to the Dose Unit is it is output to a free text field because of the DOSEUNIT_TO_DOSETEXT or DOSEUNIT_TO_DRUGINFO options.

DRUG_INDICATION_TO_INFO

If the Drug Indication does not map to MedDRA, it is output to Drug Additional

If ’Y’ and the SUPPRESS_NON_MEDDRA_TERMS option is True for the receiver, the unmapped indications are written to <drugadditional>

INDICATION_LABEL The prefix for unmapped indications when they are converted to free text.

This value is prefixed to the unmapped indications when they are written to the drugadditional tag.

EPISODE_TO_MEDHIST If the Medical History term does not map to MedDRA, it is output to free text medical history comments.

If ’Y’ and the SUPPRESS_NON_MEDDRA_TERMS option is True for the receiver, the unmapped indications are written to <patientmedicalcomment>

EPISODE_LABEL The prefix for unmapped medical history terms when they are converted to free text.

This value is prefixed to the unmapped medical history terms when they are written to the patientmedicalcomment tag.


Import processing


Import processingAERS includes a number of special features to handling various idiosyncrasies of incoming data. Many of these features are controlled by sender-specific rules that govern the import process and the way in which the incoming data is loaded into AERS. The sender-specific rules are managed in the IMPORT_RULES table. In addition, there are import functions that apply to all inbound message processing. These include the possibility that drug names need to be derived prior to the load as

PARENT_EPISODE_TO_MEDHIST

If the Parent Medical History term does not map to MedDRA, it is output to medical history comment field.

If ’Y’ and the SUPPRESS_NON_MEDDRA_TERMS option is True for the receiver, the unmapped history terms are written to <parentmedicalcomment>

PARENT_EPISODE_LABEL

The prefix for unmapped parent medical history terms when they are converted to free text.

This value is prefixed to the unmapped parent medical history terms when they are written to the parentmedicalcomment tag.

LABRESULTS_TO_NARATIVE

If the Lab results comments field are too long for the field, they are continued in the narrative.

If ’Y’ and the SUPPRESS_LONG_DATA option is True for the receiver, the excessive lab text comments are written to <narrativeincludeclinical>

LABRESULTS_LABEL The prefix for continuation of the Lab Test results comment when they are converted to free text.

This value is prefixed to the Lab Test results comment when they are written to the narrativeincludeclinical tag.

HIDE_REPORTER_NAME

Replaces the reporter name with initials and suppresses other reporter details.

If ’Y’ the report first name, middle name, and last name are sub-stringed to one character and all other details (address, phone, etc.) are suppressed from the output.

USE_DRUG_APPROVALS

Retrieves the sender and receiver details from the Drug Approvals table rather than the run-time parameters or the Receivers table. This feature allows customers to define product-specific sender and receiver details.

If ’Y’ AERS uses sender and receiver details in the Drug Approvals table rather than the runtime parameters. AERS uses the standard submission tracking logic to identify the appropriate approval record to pull the specific details from. In addition, the E2B report includes a Drug Name parameter if needed to identify the approval. If details are found, these are included in the file. If not (or if the option is ’N’) then the standard details are provided (sender details from the run-time parameters, receiver details from the E2B_RECEIVERS table.

GATEWAY_DOWN A flag indicating whether the recipient gateway is down.

Y - If a recipient’s gateway is down, the E2B message or the acknowledgement is not written to the output file directory, but it is created and stored in Portal. It is expected that in these conditions, an alternative delivery mechanism is in place to ensure that the information is received in a timely fashion.


Import processing


well as the provision of a full user exit that allows customers to add any type of custom message pre-processing.

The AERS E2B import dynamically adapts to different implementations of the E2B specifications. For example, in the MedDRA coded fields, the sender may use the numeric term id or send the text term. If the field value is numeric, the import interrupts it as a code otherwise it treats it as a text term. The E2B import rules table controls how the data is stored in AERS. The import rules table is keyed by the senderid. For details on the import rules table refer to the Import Rules section.

E2B import is managed by Sender. For each Sender, you define characteristics of the incoming data based upon the standards you agree to with your trading partner.

To create a new sender:

1. Select the E2B Import Rules tab from the Global Maintenance subsystem.

The E2B Import Rules screen displays.

2. Click the Add Record button or select Edit=>Add Record.

3. Key in all fields. See following section for details on theE2B_IMPORT_RULES columns. Additional detail can be found in the Oracle AERS Reports TRM, available from Oracle Support.


The sender is saved to the database.

Import RulesThis section contains details on the E2B_IMPORT_RULES as well the user exit API that allows you to add additional processing of inbound E2B messages.

E2B_IMPORT_RULESThe E2B_IMPORT_RULES table contains the sender-specific import rules configuration.


USE_SENDER_CASE_ID Use the sender’s Case ID when importing cases.

If ‘Y’ the sender’s report id is used as the case-id for the incoming case. If the case-id already exists in the AERS database the incoming report is assumed to be an update.

If ‘N’, new cases are added with a $E2B case id.

Import processing


USE_SENDER_RECEIVE_DATE

If the sender is a part of the user’s organization or an agent (such as a CRO), the clock should start when the sender learned of the cases.

On the other hand, if the sender is another manufacturer or a regulator, the clock should start when the organization learns about the case. Because it is possible for the receiver to delay processing the E2B file, AERS takes the most conservative approach possible and uses the E2B message date.

If Y, the receive date in the AE_ACTIONS record is set to the sender’s value.

If N, it is set to the message date.

ALLOW_UPDATES This option controls whether a case can be updated by the import process.

If “Y”, the new data replaces case data in AERS.

The import finds the case to update using in the E2B case-id’s in following order safetyreportid, authoritynum, companynumb and othernumb.

The data in the following tables is deleted:

AE_SUSPECT_DRUGS (and all children)

AE_EVENTS

AE_REL_INFO (and all children)

AE_LAB_TESTS

AE_OTHER_DX

All the E2B fields in AE_CASES are updated.

An AE_ACTIONS record is created using the rules defined above.

If “N” the import creates a new case for each report in the message file.

ENFORCE_VERSIONS_ON_UPDATE

The E2B DTD provides the capability of versioning reports. The intent is to allow the user to distinguish a true update to a case from a duplicate transmission. Unfortunately, this is not a required field and there are no set rules for how the version number should be handled.

If “Y”, the import only updates the case if the version number is higher than the version number of the last applied update.

If the version number is equal or lower, the import does not change the case data. It adds an appropriate note in the master document record.

If “N”, the report is processed without checking the version number.


Import processing


ENFORCE_VERSIONS_ON_UPDATE

One alternative to using the version numbers to distinguish duplicates from updates is to use the receipt date.

If “Y”, the import only updates the case if the receipt date is higher than the latest receive date for the case.

If “N”, the report is processed without checking the version number.

IMPORT_EVENTS_TO_DRUGS

The E2B format includes an unstructured assessment of causality at the event to drug Level.

If Y, the data is imported per the rules described in the field details section.

If “N” the data is included in the case comments only.

NORMALIZE_DRUGS In AERS, indications and dosages are child records of the suspect drug, and lots are children of dosage records. The E2B has one drug record for all these relations. If a patient receives the same drug for two indications and at two different dosages, the E2B file contains at least four drug records for the one suspect drug.

If “Y”, the import does not create duplicate drug indication and dosage records. It uses the following keys to detect duplicates:

DRUG_NAME, INDICATION, ALL AE_DOSAGES FIELDS.

If “N”, the import creates a DRUG, INDICATION, DOSAGE and, if lot number present, a DOSE LOT record for each drug record in the message.

EDI_HEADER Data appended at the beginning of the file to support the gateway

EDI_TRAILER Data append at the end of the acknowledgement message to support the gateway

DB_SERVER_ACK_OUTPUT_DIRECTORY

The name of the directory to place acknowledgment messages.

This directory must be defined in the util_file_dir parameter in the init.ora file for the database.

INCLUDE_EDIFACT_ENVELOPE

Y=Add the message dependent values to the header and trailer per the EDIFACT rules

ACK_ENCODING The name of the character set used to encode the message. If edi_header includes an <?XML> tag. The encoding attribute is set according to this value.

AUTOMATIC_ACK_FLAG

This flag controls when the acknowledgement is handed off the gateway

I - Send automatically immediately upon import

S - Send when all the cases in the message are either saved or deleted.

M = Send manually


Import processing


Pre-import user exitIf defined, the E2B import calls the customer's code to pre-process an incoming E2B file. The incoming message can be either an ICSR or acknowledgment. It is invoked just after the AERS import has determined the file is valid, but before any data is written to the AERS database. The user exit function returns a status code that tells the user whether or not to proceed with the import. The customer's code has full access to the message content and the AERS database. Some of the more likely uses for the exit include logging imports, determining the validity of the data for import, changing the data that is imported, extracting unknown dictionary terms and adding them to the AERS dictionary or code lists.

The name of the pre-import function is defined in the E2B_IMPORT_RULES table. It is called from the import using dynamic SQL. This allows the customer to define a different function for each sender.

The specification for the function is:

Function USER_E2B_PRE_IMPORT (p_e2b_doc IN OUT XMLDOM.DOMDOCUMENT,

GATEWAY_DOWN A flag indicating whether the recipient gateway is down.

Y - On import, a message is generated because it is possible that the acknowledgement message was not transmitted because of this condition.

CREATE_REPORTABILITY_RECORD

This flag is reserved for a possible future enhancement and not implemented in 4.5.

The E2B format includes a license number for each drug. This field is the license number that the drug was administered under.

If “Y”, the import creates a reportability record to store the license number.

If “N”, the license number in the input is treated as a non-importable field and it is stored in the case comments.

CREATE_REGISTRY_SOURCE

This flag is reserved for a possible enhancement. It is not implemented in 4.5.

The E2B specifications distinguish between the role of primary sources and senders.

However, the ICH has issued contradictory statements on whether to treat registries as primary sources. In the E2B specifications, the primary source is the party that first reports the case: e.g. the doctor or the patient. A regulatory, registry or other manufacturer is a sender of the cases. However, the PSUR specification recognizes a registry as a possible source.

If ‘Y’ the import creates a Report_Source record with a type of “R”, for Registry. Use the sender fields to fill in the details of this Report Source record.

If “N” the import does not create a registry source record.

This flag does not effect the generation of report source records based on the primary source data. Since the primary source is a required element, if this flag is “Y” the result are two report source records.


E2B Data Mapping


p_message OUT varchar2) return number;P_E2B_DOC: The output of the Oracle XML Parser. Refer to the parser documentation. P_MESSAGE: A message composed by the customer's code. Depending on the return code, it will be written to the E2B acknowledgement or import report. Return values: In the following list shows the valid return values and the action taken by the AERS import after receiving the return value. Return codes 1 and 2 only apply when the incoming message is an ICSR.

0 -- Proceed normally, if present the message is included in the import report.1 -- Proceed normally but write the message content to the acknowledgement message 2 -- Abort processing and generate an acknowledgement with a status 01 (invalid file) including the message.3 -- Abort processing immediately without writing an acknowledgement. The abort will be recorded in the AERS import report. No exception is raised.

Unless there is an exception, the AERS import commits the current transaction after the user exit is called.

The import does not handle Oracle exceptions raised by the user exit. Thus the error is simply passed up to the next level. If the import was started interactively, the AERS front-end displays the Oracle error message and roll back the transaction. The batch import rolls back the transaction, write an E2B import log entry, and re-raise the exception so that it is recoded as a failed database job.

E2B Data MappingOracle AERS uses the same rules and architecture for creating E2B export files as for processing E2B import files. Consequently, E2B import and export share several general rules. Shared rules enables AERS to manage E2B data in a structured manner, and provides AERS users better support for their individual data management process and data standards.

Coded FieldsMany E2B fields require numerically coded values for the associated data items. The data items are stored in AERS using customer-defined codes, which may not match E2B values and therefore require translation. AERS handles data item translation via the AERS code list language feature.

Both E2B import and export procedures use the code list configuration to determine if a value should be translated. If a code list is associated with the target field in the FIELD_ATTRIBUTES table, the E2B or ISO language code is used to complete the translation. To support the internal business practice of companies collecting more detailed information than required in the E2B specification, several AERS codes can translate to the same E2B value. Upon E2B import, AERS uses the code list entry when the target field's USER_ENTERABLE flag = 'Y'.

The dynamic use of code lists allows customers to use company-standard lists and translations, such as causality assessments, which are not standardized in E2B.

In the case where an E2B field does not directly map to an AERS field, the language 'E2B' is used in translating the AERS data items. For E2B fields defined by the International Standards Organization (ISO) (e.g., the 'country' field), the language 'ISO' is used.

E2B Mapping TableE2B Import and Export uses the E2B_MAPPING table to associate AERS tables and columns with the appropriate E2B tags. The E2B_MAPPING table reduces the need for

E2B Data Mapping


hard-coding literal values in the E2B import and export processing packages. The PROCESSING_RULE column specifies if the mapping is one-to-one (i.e., 'SIMPLE'), or if it requires more complex processing.

Other Case ReferencesAERS stores reference numbers generated by external systems into the AE_OTH_CASE_REFS table. The reference numbers include the static safetyreportid for the case as well other ADR system case identifiers and medical record identifiers. The safetyreportid is created when the submission wizard is initially run for the case. This creates a standard case identifier that can stay constant, even if details embedded in the ID, like the country, change in the case.

E2B import creates a record in the AE_OTH_CASE_REFS table corresponding to the sender details in the inbound message. The sender's case identifier is stored in the OTHER_CASE_ID field. The case sender (i.e. the name of the agency or institution that assigned the identifier) is stored in the OTHER_SOURCE field. The other source categorization is stored in the OTHER_SOURCE_TYPE field, and is standardized via an associated code list. Listed below is the OTHER_SOURCE_TYPE mapping details:

The E2B Import process uses the Safety Report ID in the inbound message and the Other Case Reference data and configuration to identify which AERS case is updated. The function first determines the OTHER_SOURCE_TYPE code corresponding to the ‘safetyreportid’ tag, then searches for the case where the’safetyreportid’ matches appropriate OTHER_CASE_ID. If more than one case is found, the import fails.

Dose FrequencyThe E2B and AERS have different ways to encode the dose frequency. The E2B uses three fields to represent the frequency. AERS uses a single code field. The AERS codes are usually the standard Latin prescribing abbreviation. The frequency codes table provides the mechanism to translate between the two. On export, the AERS code provides the key into the table. Since a code can resolve into multiple E2B

Note: The E2B import and export code is not designed to be completely table-driven. The code and table content are tightly coupled. It is not recommended that users change any data in the E2B_MAPPING table.:

Tag OTHER_SOURCE_TYPE

safetyreportid E2B

companynumb CO

duplicatenumb DUP

authoritynumb AUT

othernumb OTH

patientspecialistrecordnumb SPN

patienthospitalrecordnumb HPN

localreportnumb RCV

safetyreportversion VER

patientgpmedicalrecordnumb GPN

E2B Automation Features


representation, the entry with the preferred flag set to ‘Y’ is used. On import, the combination of the three fields from the E2B form the key.

The E2B format also contains a dose description field, which is used when the separated fields cannot describe the actual dosing regimen, such as in the case of titration. In the AERS data model, the dose description overrides values in the individual fields.

E2B Automation FeaturesOnce a stable trading partner relationship is established, companies typically want to automate the exchange of E2B files and acknowledgements. This automation relies heavily on the automation features of the specific electronic gateway solution used by the AERS customer. The most common form of gateway automation is to read from and write to predefined server directory locations to process outbound and inbound messages.

Oracle AERS compliments this automation approach with two broad features:

1. The ability to write outbound messages (E2B files and post-import acknowledgements) to a predefined directory location.

2. The ability to periodically read, upload, and process inbound E2B and acknowledgement messages from a predefined directory location.

The automated processing of inbound E2B and acknowledgement messages is controlled by a PL/SQL package called E2B_AUTOMATION. The import process is managed by a procedure called Batch_Import. The customer creates one or more DBMS jobs that call BATCH_IMPORT at whatever frequency a customer desires, passing the required runtime parameters.

The automated E2B gateway interface is implemented using the same E2B package used in the manual import and export. Thus all the processing rules defined in the main E2B specification hold for the automated import hold for the automated import. The process by which an E2B file is imported will not impact the subsequent AERS E2B processing functions. From the point of view of the mainline AERS processing, it will not matter if a file was imported manually or automatically. For example, the E2B and acknowledgement files are stored in Portal.

Supported Automation Features■ Automatically import E2B files after the gateway places them in the inbound

directory.

■ Provide an option to place the acknowledgement message in a file system directory at the time of import. The name of the directory should be controlled by E2B_IMPORT_RULES table for the recipient of the acknowledgement (i.e., the sender of the E2B message).

■ Add the gateway envelope (e.g. EDIFACT headers/trailers) to outbound acknowledgements.

■ Log the automated import and export of files. The log has one row for each attempt to process a file. The log is used to control which files are processed by the BATCH_IMPORT procedure.

■ Multiple automated imports using input from different sources (directories) can be scheduled to run on independent schedules. There is no operational requirement that two import processes be able to process data from the same source



simultaneously. If two such processes start they should not interfere with each other's work.

Gateway downThis feature allows the users to stop AERS from writing a message to the file system directory when the receiver cannot receive an electronic report or the sender cannot transmit the message because the gateway is down.

The GATEWAY_DOWN column in E2B_RECEIVERS and E2B_IMPORT_RULES controls this feature. If the flag is 'Y', the system does not send an E2B message. If an E2B report is not sent, a warning message is added to the error log. If an acknowledgement message is not sent, a warning is included in the portal item description.

Gateway Event and MDN ProcessingThe AERS E2B automation packages includes the ability to process gateway events including the receipt of Message Disposition Notification (MDN). The MDN is important because the EMEA uses the MDN as the official notification that a submission has been received. The date on the MDN can be used to prove that the 15 day reporting deadline has been met. The architecture of the AERS gateway event processor goes beyond the MDN requirement.

The mechanism is that the gateway writes an XML structured file for each event as it occurs. Just as with E2B files, AERS polls this directory looking for new files. When a new file is found AERS writes the significant fields to the event in the E2B_LOG table. For MDN received events, AERS also updates the submission mail date for each of the cases that was included in the E2B Submission. AERS correlates the MDN with the original E2B message using the E2B message ID. This places a burden on the gateway to parse the E2B messages it acquires for the message ID and includes this ID in each event it passes back to AERS.

The schema and format of the content of the XML messages varies between Gateway vendors. The following table describes how Cyclone events are used to populate the the E2B_LOG. The following table describes how an event populates the columns in the E2B_LOG.

E2B_LOG Column Tag or Notes

TS The database timestamp when the event is processed by AERS.

Action Always ’I’ for import.

Directory The directory the file was pulled from.

Filename The OS filename.

Status A one letter code. The same codes are used from E2B imports.

ERROR_MESSAGE An internally generated error message or note.

E2B_MESSAGE_NUMBER The value of the messageid tag from the E2B message.

CycloneEvent/metaData/MessageSnapshot/DocumentId

MESSAGE_TYPE G for gateway event.

LOCAL_GATEWAY_TS The gateway’s timestamp when the event is created. The format is ddMONYYYY hh24:mi:ss time zone.

CycloneEvent/created



The directory used for events should be different than the directory used for E2B message imports. The fundamental reason is that both the gateway vendors or the regulators routinely violate the XML standard for encoding (character set).

Batch_ImportThe automated E2B import is implemented as the BATCH_IMPORT procedure in the E2B_AUTOMATION package. BATCH_IMPORT is run as a database job, connected as the AERS schema user.

The definition of the procedure is:

E2B_AUTOMATION.Batch_import ( p_dir varchar2, p_caid number, p_portal_folder_id number, p_delete_after_processing varchar2);

P_DIR is the directory that is scanned for new files. The AERS schema account must have read access to the directory using database java and the util_file package.P_CAID is the portal content area the file is uploaded to.P_PORTAL_FOLDER is the Item ID of the portal folder in which the file is stored.P_DELETE_AFTER_PROCESSING is a flag. If 'Y', the batch import deletes each file after processing.

When batch_import is initiated, it loops though the list of files in the directory and processes each file.

1. If the E2B_log shows that the file has been processed (status C or A), it is bypassed.

2. The file is uploaded to the portal folder.

3. The E2B package is called to import the file. The E2B package auto-detects the message type (ICSR or acknowledgement). In the case of an ICSR the import process generates the acknowledgment and if the import rules are set for an immediate acknowledgement the E2B package hands the acknowledgment message off to the gateway, including logging.

4. The results of the import are written to the E2B_log. The information about the contents of the E2B message is retrieved with a call to the E2B Package (E2B.GetImportInfo).

5. If there is an exception that indicates an invalid file, such as the file could not be parsed, had an invalid message type, or unknown version, the import completes the log record with a status of 'A' aborted and the next file is processed.

6. If any other Oracle errors occur, batch import writes a log record containing the error message and then raise the error so that it can be trapped and reported by the database job manager.

GATEWAY_MESSAGE_ID The gateway’s internal ID for the E2B Message.

GATEWAY_EVENT_TYPE CycloneEvent/type

REMOTE_PROCESS_TS For an MDN type event, time stamp the MDN was created by the partner gateway.

E2B_LOG Column Tag or Notes



E2B_LOGThe E2B_LOG table logs automated import and export actions at a file level.

Error handlingThe following error handling features are required for the automation:

■ There is no control in the batch import that forces files to be processed in any particular order. The E2B_IMPORT_RULES should be configured to prevent an earlier version of a case from being loaded.

■ A log record should be written whenever an attempt is made to process a file, even if the transaction is rolled back.

■ In general, the batch import does not need to write to the AERS error log as it would be redundant with the E2B_LOG. However, the E2B_LOG can only report one error message. If an exception cascades through several exception clauses, it may prove useful to write the low level messages to the ERROR_LOG.

■ Invalid files do not cause the batch import to fail. If an invalid file is encountered, an error is logged and the next file is processed. Users may subsequently fix the offending file and import it manually, or else request a corrected file from the sender and attempt to re-import the file.

Column Description Values

ACTION Is the file being exported or imported

I - Import E = Export

TIMESTAMP Oracle date when the action occurred

DIRECTORY The directory in which the file was placed in

FILENAME The name of the processed file

STATUS Did the import succeed or fail

C = Completed A=Aborted. Processing was stopped programmatically without completing. F=Failed Processing was stopped because of an Oracle exception.

ERROR_CODE The oracle error number Usually null if the operation completed normally, e.g. ORA-20001

ERROR_MESSAGE Error message

MESSAGE_TYPE The type of message such as E2B or acknowlegementacknowledgement

The value associated with the messagetype tag of the file being processed.

ICHICSR

ICHICSRACK

MESSAGE_NUMBER The E2B message number.

The value associated with the messagenumb tag of the file being processed

NUMBER_OF_REPORTS

The number of safety reports in the message.



■ Operational exceptions, such as failed file I/O or limited tablespace, raise an Oracle exception and cause the batch import to fail. This allows the normal database job exception handling procedures to detect and alert the database administrators to the problem.

Configuring AutomationThe E2B Automation features are designed to run as a database job. Like any database job, E2B Automation can be scheduled to run at any interval. Customers can establish multiple database jobs should their gateway configuration require it (that is, specific jobs can be scheduled to read from different server directories). The configuration can be done manually, or you can run the CreateE2BAutomationJobs.SQL program included in the tools\dba directory.

Creating server directoriesE2B Automation is designed to read E2B messages (ICSRs) and acknowledgements from specific directories on the database server. These directories correspond to the directories where the electronic gateway writes its inbound messages.

Once these directories are established, they must be listed into util_file_dir initialization parameter for the database (init.ora).

Granting operating system permissionsThe AERS Schema owner runs the Batch_Import procedure. This procedure reads and deletes files from the operating system. As such, the schema must be granted read and delete permissions on the server directories.

To grant file system permissions, execute the following commands as SYS:

SQL> exec dbms_java.grant_permission('<AERS Schema Owner>', 'SYS:java.io.FilePermission', '<E2B directory>', 'read');

SQL> exec dbms_java.grant_permission('<AERS Schema Owner>', 'SYS:java.io.FilePermission','<E2B Directory>\*', 'delete');

Creating the database jobThe E2B Automation job is a standard database job. To create the job, execute the following SQL command:

exec dbms_job.submit (jobno, 'e2b_automation.batch_import(’’<E2BDirectory>’’,34,3091,''Y'');', sysdate, 'sysdate + 10/1440');

This example creates a job that polls the directory every 10 minutes and deletes and file that it successfully uploads.



Creating and managing document templates 16-1

16 Creating and managing document templates

A common use for pharmacovigialnce and complaint management is the generation and tracking or standard correspondence such as Phone Calls, Site Visits, and Follow-up letters. Oracle AERS supports the ability to generate standard letters or correspondence, which can include case data. This feature is supported by creating PL/SQL Server Pages, which are then loaded into the database and managed as stored procedures. The user can then click on the Generate Letter icon to see a list of standard templates available, then generate a letter for the active case.

Document templatesTo add new templates you must:

1. Develop the template according to the rules below.

2. Load the PL/SQL Server Page into the database.

3. Add a record in the LETTERS table corresponding to the new template.

Creating the template PL/SQL The basis of the document template feature is a set of PL/SQL Server Pages (PSP), created using a specific syntax to allow data from the case to be substituted into the template and displayed in a browser window.

To create the PL/SQL Server Page:

1. Review the sample letters included with Oracle AERS 4.5. These can be found in the \aers\server\schema\is\psp directory of the staged installation files used to support an installation. If these files are no longer on your file server, you need to perform a "Server Installation" of Oracle AERS.

2. Once you have reviewed the sample templates, you may either edit the template that best fits your requirements or you can simply create your own.

If you are creating a new template, please note that Oracle has adopted a standard of prefixing the procedure name with "LETTER_" so the defined procedure is uniquely identifiable within the database after loading.

Note: These instructions assume a solid working knowledge of PL/SQL and HTML. Oracle AERS 4.5 includes examples of several different templates to help you get started developing your specific templates.

Document templates


Templates can be optionally passed two parameters: The current contact sequence number (if Contact addressing is being used) and the Case ID. Most templates use both.

3. As you are developing, you can load and test your template using the instructions below.

Loading the templateOnce the PSP package is created, it must be loaded into the database instance.

1. Save the program in a secure directory according to your internal change control policies.

2. Load the PSP program into the AERS database instance:

loadpsp -replace -user <connect string> <program name>.psp

For example:

loadpsp -replace -user aers1/aers1@aers45 AECaseSummaryListing.psp

Defining the template in the LETTERS tableThe final step is adding an entry in the LETTERS table to define the new template to Oracle AERS. This step is performed from the Administrator Console within Oracle AERS.

The entry in the LETTERS table must be made at each site.

1. Launch Oracle AERS using an account with administration privileges.

2. Navigate to the Administrator Console by selecting the subsystem icon or selecting Administrator Console from the Maintenance menu.

3. Select the Letters Templates and complete the information as follows:

Display Number: The overall sequence number for the display of the templates within the Generate Template dialog box presented to the user.

Letter Name: The name of the template, as displayed to the user in the Generate Template dialog box

Procedure Name: The name of the stored procedure as loaded into the database (step 2 of Load the template, above)

Cont Seq Nbr: An optional parameter if the template has been designed to accept the Contact Sequence Number as an input variable.

Case ID: An optional parameters if the template has been designed to accept Case ID as an input parameter.

Role: The AERS Application Role required for a user to generate the template.

Category: The name of the Folder that contains the template in the Generate Template dialog box.

Managing programs and reports 17-1

17 Managing programs and reports

Oracle AERS enables you to perform the following tasks to manage programs and reports:

■ Installing new reports

■ Defining report parameters

■ Deleting reports

■ Configuring Oracle AERS reports

■ Configuring code lists used by reports

■ Configuring default values for program parameters

■ Configuring report parameter cross-validation

■ Customizable views used by reports

■ Adding the company logo for MedWatch report

Installing new reportsOracle AERS comes with pre-installed regulatory and non-regulatory reports. You can develop and install additional Oracle Reports.

There are two steps to installing new reports:

1. Registering the report to the Oracle Reports Security Server within Portal.

2. Installing the report and setting the report parameters on Oracle AERS.

If you do not install a report on both the Oracle Report Server and Oracle AERS, users cannot access or run the report.

Registering new reports on the Oracle Report Security ServerTo install new reports, you must have a report executable (.REP) compiled with a compatible Oracle Reports version.

To register a report on the Oracle Report Security Server:

1. Log on the AERS Portal page as the Portal User (PORTAL30) and Navigate to the Portal Home Page (HOMEPAGE).

2. Select the Administer tab, then click on the Oracle Reports Security Settings link.

The Oracle Reports Security page displays.

3. Click the Create Reports Definition File Access link.

Installing new reports


The Oracle Reports Security wizard appears.

Enter the data as follows:

Application: AERS_REPORT_APP

Report Name: The name of the report. User the same name as the File Name, without the extension.

Reports Server: AERS_REPORT_SERVER

Oracle Reports File Name: The name of the Oracle Report executable as stored in the opapps40/aers directory, without the .REP file extension.

Description: optional description (does not surface to users).

4. Click Next.

The Users and Groups page displays.

Add Grantee AERS_IF_USER with MANAGE privilege.

5. Click Next.

The Calendar page appears.

Leave this blank.

6. Click Next.

The Required Parameters Page displays.

Select Destination Type: Cache.

Select Destination Format: PDF.

7. Click Finish.

Installing new reports on Oracle AERSMost reports have a pre-defined set of parameters necessary to produce the output. Parameters are the criteria you specify when installing a report. Parameters can have a default value, be mandatory or optional, and be visible or invisible. If you have not previously used the parameter name in Oracle AERS, you must install and define the parameters at the Report Parameters screen. When defining parameters for a report, you also define the questions or prompts that you want the user to view. For example, if you want the user to identify the Case ID, you could key in "What is the Case ID?" as the parameter prompt.

To install a report on Oracle AERS:

1. Press the Administrator Console subsystem button or select Maintenance=>Administrator Console from the Oracle AERS main menu, then select the Report Maintenance tab

The Program Maintenance screen displays.

2. Click the Add Row button.


4. Do either of the following:

Note: Report maintenance is performed in the local Oracle AERS application.

Defining report parameters



Oracle AERS saves the Report and Report Parameters to the database.

Defining report parametersAll report parameters are defined in the Program Parameters Maintenance screen in the Oracle AERS Data Maintenance subsystem. For any report parameter, you can attach a code list by:

■ Attaching an existing code list.

■ Creating a new code list (at the Code List Maintenance screen).

■ Writing an SQL statement for the values you want to display at run-time.

You should specify a datatype with the Parameter Name. There are four possible datatypes that can be defined with a Report Parameter:

The values entered in the Program Parameters Maintenance screen are subsequently assigned to reports in the Program Maintenance screen. When a report is run, the assigned parameters display in the Program Parameters screen where the User is required to fill in a value for each parameter.

To create or modify a report parameter:

1. Press the Administration subsystem button or select Maintenance=>Administrators Console from the Oracle AERS main menu.

2. Key in the values for the parameter.

■ Parameter Name: The name of the parameter as required by the report.

■ Force Case: Force the user's parameter value into upper case (recommend U for all parameters).

■ Data Type: The data type for the parameter. Setting this correctly adds data type validation to the parameter.

■ Code List Name: The name of the code list associated with the list.

■ Code List Text: A SQL statement to be used as a code list. The same syntax is used here as in the Data Entry RG_ATTRIBUTES.

If… Then…

You do not want the parameter visible to users Click the Visible? checkbox to clear it.

You want the parameter visible to users Go to the next step.

Datatype Description

CHR Text format. Any alpha-numeric combination is acceptable.

DAT Oracle full date: 07-OCT-1997 15:44:18. When the User enters a date for a parameter configured in DAT format, the date is stored as GMT/Universal time in the database, but may display as local time to the User.

LOV List of Values/Code List.

PDT Partial Date. Acceptable formats: DD-MON-YYYY, MON-YYYY, MONYYYY, MONYY, YYYY, or YY.

Deleting reports


■ # Cols: The number of columns returned (3 by default for Oracle AERS codelists, otherwise determined by the SQL statement in the Code List Text column).


Oracle AERS saves the report parameter to the database.

Deleting reportsYou can remove reports from the Oracle Report Server or in Oracle AERS.

Removing reports From the Portal Reports Security RegistryTo delete a report on the Oracle Report Server:

1. Log on the AERS Portal page as the Portal User (PORTAL30) and Navigate to the Portal Home Page (HOMEPAGE).

2. Select the Administer tab, then click on the Oracle Reports Security Settings link.

The Oracle Reports Security page displays.

3. Enter the report name that you want to remove in the Edit Reports Definition File Access edit box under the Reports Definition File Access portlet and click Edit.

The Develop report page appears.

4. Click Delete.

Portal confirms your selection.

5. Click Close.

The Reports Security Settings Page appears.

Deleting reports on Oracle AERSBefore deleting a report in Oracle AERS, you must first delete related child references in the Saved Parameters and Process Queue screens.

To delete a report on Oracle AERS:

1. Press the Administration subsystem button or select Maintenance=>Administrator Console from the Oracle AERS main menu.

2. Select the Report Parameters tab.

The Report Parameters screen displays.

3. Select a report from the Navigator panel or by querying the form.


The report disappears from the screen.


You do not receive a prompt. Oracle AERS deletes the report from the database.

Configuring Oracle AERS reportsWhile external authorities largely dictate the format of each regulatory report, there is considerable variation in the approaches taken by companies in populating the report

Configuring code lists used by reports


fields. To accommodate this diversity, Oracle AERS has implemented several features to support report configuration:

■ Report Language Code List Values – Oracle AERS uses these values whenever report logic is dependent on specific code list values (e.g., Serious Flag = 'Y' to check the Serious box on the report). Oracle AERS allows clients to modify the code list values, therefore, the report must have a way to respond to the different values (e.g., Serious Flag = 'T' rather than 'Y' to check the Serious box on the report). If you alter a code list, you must also include the correct report language values in the code list.

■ Report Function Codelists – These codelists control special report features in the reports such as follow-up counting and setting derived data fields. You can tailor these codelist values to alter the way in which reports behave.

■ Report Views – You can use these views to populate many of the fields in each report, and redefine them as part of the installation and implementation process to track closely with existing or emerging approaches to handling the regulatory report.

■ Stored Procedures – You can use these procedures to derive values that cannot be handled in views because they involve procedural manipulation of the data. You can modify, then reinstall, stored procedures to allow clients to alter the derivation logic of some fields. In this version of Oracle AERS, stored procedures are not customizable. In future versions of Oracle AERS, customizable options are implemented for stored procedures.

■ Report Parameters – You can use this feature to provide an interface for users to select report options.

Configuring code lists used by reportsOracle AERS reports use codelists to decode customer-specific coding standards into standard report terminology, and to control specific report functions.

The decoding process involves mapping the codes used in data capture and stored in the case data to standard report fields. For example, the MedWatch report has checkboxes to represent patient sex. However, Oracle AERS allows customers to capture patient sex however they want. The Oracle AERS reports check the Male box if the value is M and check the Female box if the value is F. If a customer decides to code Patient Sex as 1 for Male and 2 for Female, they must also modify the translation of these values into the standard report terminology. Oracle AERS uses the same mechanism to manage this translation to report terminology as is used to manage multi-lingual code values.

Customers can update codelists that control report functions to alter the default report behavior. For example, the 10-Day box, which still appears on the MedWatch even though the underlying regulations have changed, is checked by default for expedited MedWatch reports filed under the IND. If you decide you want to change the behavior to check the 15 day box (historically relevant only for non-IND reports), you update the values in the US_REPORT_FORMS table.

Managing report decode valuesThe Core reports use code lists to translate the client-defined values (stored in the case data) to values usable by the report programs. The code lists are the same mechanism that allows multi-language support. The Core reports rely on a translation to the 'RPT' language. The default Oracle AERS code lists ship with 'RPT' values, but if the client

Configuring default values for program parameters


changes or adds to the code lists, you must change or add to the 'RPT' values. In each of the code lists used by the reports there must be an 'RPT' language translation for each code defined. The following is the list of fields decoded for use in reports. The Table Name and Column Name identify the database element being decoded. The Default Code List is the code list name attached to this field when shipped with Oracle AERS. Clients can change these, except for the UTIME code list. The Output Value is checked by the report program. When only "Y" is listed, the programs check for "Y" or any values not "Y."

Configuring default values for program parametersProgram (report) parameters may have default values that you can dynamically configure using a SELECT statement. Default values are defined in the Default Value column in the PROGRAM_PARAMETERS table (and Program Maintenance screen).

Dynamic default values are useful for parameters such as the As Of Timestamp (ASOF_TS) parameter. (This is the time that displays on the report.) You can define the default value for the ASOF_TS parameter to pre-fill with the time the report was requested, or it can have a blank default value.

Syntax for a default value that supports pre-filling a blank value is described below.

For default values starting with '=', the application interprets the remaining string containing a SELECT statement and evaluates the default value based on that select statement. For example, for reports in which the ASOF_TS should be pre-filled with the current system time, enter the following line in the default value for that report:

= (SELECT to_char(sysdate, 'DD-MON-YYYY HH24:MI:SS') COL1 from dual)

The '=' feature is a universal feature for all program parameter default values, and is not restricted to the ASOF_TS parameter.

Configuring report parameter cross-validationThese validation checks ensure that required report parameter fields contain legitimate values. Validation occurs before the report is executed, and an error message displays if a value is missing or invalid.

Note: The column must have the alias COL1 defined.

Table 17–1 Descriptions of validation functions

Validation Functions Description

RPCK.OneOnly(param1, param2, …, param5) Must specify one and only one of the listed parameters

RPCK.AtLeastOne(param1, param2, …, param5)

Must specify at least one of the listed parameters

RPCK.AllOfThese(param1, param2, …, param5) Must specify all of the listed parameters

RPCK.None(param1, param2, …, param5) Specifies none of the listed parameters

RPCK.IfEqAllOfThese(KeyParam, ChkVal,param1, param2, …, param5)

If the value for KeyParam is equal to ChkVal, then all of the listed params must be specified (see "Examples" on page 17-7)

RPCK.IfNotEqAllOfThese(KeyParam, ChkVal,param1, param2, …, param5)

If the value for KeyParam is NOT equal to ChkVal, then all of the listed params must be specified (see "Examples" on page 17-7)

Configuring report parameter cross-validation


There is also a helper procedure in the RPCK package that is useful when you write your own report parameter validation function.

Examples1. RPCK.OneOnly('CASE_ID', 'CASE_LIST_NAME', 'SAVED_QUERY')

This rule checks to ensure the CASE_ID, CASE_LIST_NAME, or SAVED_QUERY parameter has a value.

2. RPCK.IfEqAllOfThese('DRAFT_SUBMISSION', 'S', 'AGENCY')

This rule checks to ensure if the DRAFT_SUBMISSION parameter has a value of 'S', then parameter AGENCY must be specified.

3. RPCK.PdtOnBefore('START_DATE', 'END_DATE')

This rule checks to ensure that the partial date parameter START_DATE must be on or before the END_DATE.

4. RPCK.DatOnBefore('FROM_TS', 'TO_TS')

This rule checks to ensure that the full date parameter FROM_TS must be on or before the TO_TS.

Multiple report parameter validation rules can be ANDed together. For example, if the 'CIOMS I' report Parameter Validation field is specified to be:

RPCK.OneOnly('CASE_ID', 'CASE_LIST_NAME', 'SAVED_QUERY') AND RPCK.IfEqAllOfThese('DRAFT_SUBMISSION', 'S', 'AGENCY')

Then the Run-Reports front-end screen submits a CIOMS I report only if:

One and only one CASE_ID, CASE_LIST_NAME, or SAVED_QUERY parameter is specified, and if running a submission report, the AGENCY field is specified.

RPCK.PdtBefore(dtparam1, dtparam2) Partial date dtparam1 must be before partial date dtparam2

RPCK.PdtOnBefore(dtparam1, dtparam2) Partial date dtparam1 must be on or before partial date dtparam2

RPCK.PdtEqual(dtparam1, dtparam2) Partial date dtparam1 must be equal to partial date dtparam2

RPCK.DatBefore(dtparam1, dtparam2) Full date dtparam1 must be before full date dtparam2

RPCK.DatOnBefore(dtparam1, dtparam2) Full date dtparam1 must be on or before full date dtparam2

RPCK.DatEqual(dtparam1, dtparam2) Full date dtparam1 must be equal to full date dtparam2

Table 17–2 Helper procedure for report parameter validation


RPCK.GetParamValue(param) This function returns the parameter value, from the PROCESS_ARGS table, of the input parameter. It returns NULL if the input parameter is NULL or not found.

Table 17–1 (Cont.) Descriptions of validation functions


Customizable views used by reports


Client extensionsWhen Oracle AERS is installed with add-on reports written by the client or a third party, additional parameter validation procedures may be required. Clients can create their own parameter validation procedures, install them in Oracle AERS, and specify them in the Parameter Validation field of the Program Maintenance screen. Example 17–1 illustrates the steps involved.

Example 17–1 Client extensions example

A custom report needs to read an external file, and the file name is specified in one of the report parameters at report run-time. You want to include a validation procedure to ensure that the entered file name is valid and the file exists before the report is submitted.

You can ensure that the entered file name is valid, and that it exists before the report is submitted, by creating a new validation procedure. In this example, the procedure RptCheckFileExists can call the package function below to get the input file name:

vFileName:= RPCK.GetParamValue('FILENAME');

where 'FILENAME' is the name of the input parameter.

If the procedure does not find the specified file, the procedure should raise an Oracle application exception. It can use the standard Oracle AERS raise application exception procedure:

ServerError.Log(2, vSystemName, vModuleName, vProcedureName, 0, 'EN', -20nnn, vParam1, vParam2,…);

where -20nnn is the error code for the error message. A client can use any unused Oracle application error number in the range of -20000 to -20899. However, to ensure future compatibility, the system reserves the range -20211 to -20219 for customized report parameter validation error messages.

Insert records in the ERROR_CODES and ERROR_MSGS tables to define the proper error messages. Error codes -20201 to -20207 are currently being used by the built-in Oracle AERS parameter validation procedures, and you may refer to these error codes as examples of how to define your own messages.

Specify this procedure in the Parameter Validation field of the Program Maintenance screen. It looks similar to this:

RptCheckFileExists('FILENAME') and other validation procedures.

Customizable views used by reportsFor more detailed information on the customizable views used by reports, see the Oracle AERS Reports Technical Reference Manual (TRM).

Note: Oracle AERS provides two additional ways to validate parameters. First, by activating the 'Mandatory' checkbox in the Program Maintenance screen, you can enforce validation for individual parameters. Second, you can designate an LOV with specific values for individual parameters on the Program Parameters screen.

Adding the company logo for MedWatch report


Configuring ad hoc reporting toolsClients may install any ad hoc reporting tool that supports Oracle. A few simple guidelines follow.

In general, you can use the same Oracle user IDs used by Oracle AERS for ad hoc reporting. Create a separate role that allows users access to the tables specified for ad hoc reporting.

The DBA must define the specific tables and views users can access. To access data from historical views, users must create a record in the HIST_VIEW_TS table at the beginning of the session. The key of this record is the current session ID. The current session ID can be called by writing a SQL built-in [USERENV('SESSIONID')] that returns the session ID.

The DBA can write a stored procedure to call automatically the current session ID when the ad hoc query tool is opened.

Adding the company logo for MedWatch reportThe MedWatch allows individual company logos to display on particular reporting pages. To place your logo on the report, simply place a BMP file in t he opaapps40/aers directory, and update the Program Parameter for the MedWatch reports to reference this file.

Adding the company logo for MedWatch report


Submission management 18-1

18 Submission management

This chapter covers all aspects of configuring Oracle AERS submission management and tracking.

■ Overview of Submission Tracking functions and supporting configuration

■ Maintaining Reportability Rules

■ Maintaining Agency Reports

Overview of Submission Tracking functions and supporting configurationOracle AERS includes features to determine the reportability (where a case needs to be sent) and track all regulatory submissions of a case, including periodic submissions

These features are supported by three primary functions:

■ Submission Wizard: This is the main submission function. Its job to is to determine the reportability of the case based upon the case attributes (seriousness, expectedness, etc.), the approval history of the products, and the reporting rules of the countries that have granted approvals for the product. This function is initiated by the user at the point in the workflow where the reportability needs to be reviewed. The output of the Table-Driven Submission Wizard populates the Reportability block for the case. The function is also called by the reporting subsystem to update the reportability after a submission is generated.

■ Submission Tracking: This function is part of the reporting subsystem and is called when a report is run in Submission Tracking mode. This function validates that the requisite reportability records are present in the Reportability block and creates the submission tracking records.

■ Apply Reportability Rules: Oracle AERS defines reportability for each product approval. While this allows tremendous flexibility, it can be cumbersome to maintain. The Apply Reportability Rules function is called by the user and applies reportability rules to a block of approvals defined by the license type and agency.

These functions are supported by several global configuration tables:

■ Agency/Reports: The AGENCY_REPORTS table contains an entry for each country (or agency) and report form that you submit for your products. This table includes key elements for reportability including the reporting time frame and whether or not the report form is a local form (e.g. the BfArM report is a local report to Germany).

Note: An Agency does not necessarily correspond to a country or regulator. It can be any agency that you “submit” reports to and want to formally track. So, if you

Overview of Submission Tracking functions and supporting configuration


are a CRO, the agencies could actually be the sponsors, and the reports you track are your generated reports that you send to them prior to their submission.

■ Product Approvals: The DRUG_APPROVALS table contains one record for each approval you have received for the product. The approval includes the licensing details, the birth date for periodic reporting and a flag that indicates whether you are actively submitting to that license.

■ Reportability Rules: The REPORTABILITY_RULES table contains the table-driven submission rules. There is a set of rules for Alert Submissions, Expedited submissions, and Periodic Submissions for both clinical and spontaneous cases. There is an assumed hierarchy in these reportability types (that is if a case meets the Alert criteria, then the initial reportability record is created for an alert. This table is a child of product approvals, allowing you to define specific reporting rules for a country, license and reportability type.

■ Reportability Rules Template: The REPORTABILITY_RULES_TEMPLATE table contains template reportability rules for an agency and/or license. The rules can be applied in batch to update one or more Reportability Rules.

Running the Submission WizardThis section provides an overview of the data flow of the Submission Wizard function. The following figure highlights the key functions, data elements, and inputs/outputs of the Submission Wizard and its related functions.

A user runs the Submission Wizard to populate or update the Case Reportability, that is, to determine where and when a case needs to be submitted given the case attributes, the approval history of its products, and the reporting rules of the agencies to which the case is to be submitted.

The first step in the process is to determine the products within the case. The Submission Wizard runs for each Company Product in the Case. If the AE_SUSPECT_DRUGS.DRUG_COMPANY_FLAG = ’Y’, then the Submission Wizard determines the reportability for the product. This means that if you have a case with multiple company products, the Reportability block potentially contains reporting requirements for each of your products. For each Company Product, the Regulatory Group Name is looked-up in the AERS-TMS Dictionary. The Regulatory Group Name is then used to identify the approvals for this product.

Maintaining Reportability Rules


The Submission Wizard then creates a Reportability record for the case for each of the “active” Approvals. In creating the Reportability record, the Submission Wizard evaluates the Reportability Rules for the Approval record. The Submission Wizard first determines the Reportability Type by comparing the case attributes (such as Seriousness, Unexpectedness, Relatedness) to the reportability rule syntax. The rules are evaluated in the following order: Alert, Expedited, Periodic. If the case meets the criteria for an Alert, then the Reportability type is set to ALE. If the case does not meet Alert criteria, but it does meet Expedited criteria, then the Reportability type is set to EXP. If the case does not meet Alert or Expedited criteria, but it does meet Periodic criteria, the Reportability Type is set to PER. Finally, if it does not meet any of the criteria, the Reportability Type is set to NOT (Not reportable.

Once the reportability for the approval record is determined, the Submission Wizard looks-up the report form and time frame information from the Agency reports table. It looks for an Agency Report record matching the Approval Agency, License Type, and a Reportability Type determined in the previous step. If there is a Local Report Form for the Agency/License/Reportability, The Submission Wizard uses that report form and reporting time frame if the Country Where the Event Occurred for the case matches the Agency. The Submission Wizard then inserts a record for the agency and reportability type into the case reportability.

Maintaining Reportability RulesOracle AERS manages reportability rules at the Product Approval level. That is, each approval for each product can have specific reportability rules. For example, if a product has modified expedited reportability requirements based upon discussions with a particular regulator, you can embody those exceptions into the reportability rule for that particular product and agency by updating the corresponding approval record. To facilitate maintenance of the rules, Oracle AERS includes a “template” function that allows you to define standard reportability rules and apply them to multiple agencies or licenses.

Reportability Rule SyntaxOracle AERS uses special syntax to specify reportability rules. This syntax is designed to support the common reportability criteria (such as Seriousness, Expectedness, etc.) as well as special features like Event Term Lists. These rules are expressed as a string of tokens such as “SU” for Serious and Unexpected or “S+U” for Serious OR Unexpected.

A rule is built from the following elements:

■ D: This element corresponds to the AE_CASES.DIED_FLAG.

■ L: Death or Life Threatening: This element corresponds to the AE_CASES.DIED_FLAG. and the AE_CASES.LF_THREAT_FLAG

■ S: Seriousness. This element corresponds to the Event-Level seriousness (AE_EVENTS.SEIOUS_FLAG) if the SUBWIZ_USE_EVENT_TO_DRUG_ASSESSMENT System Parameter equals Y, otherwise it corresponds to the AE_CASES.SERIOUS_FLAG.

■ U: Unexpectedness. This element corresponds to the Event to Product-Level unexpectedness (AE_EVENTS_TO_DRG.CORE_UNEXPECTED_FLAG) if the SUBWIZ_USE_EVENT_TO_DRUG_ASSESSMENT System Parameter equals Y, otherwise it corresponds to the AE_CASES.CORE_UNEXPECTED_FLAG. Note: When country-level local unexpectedness is available, it uses the Local Unexpectedness for the Agency being evaluated.



■ R: Relatedness. This element corresponds to either the Company or Reporter Relatedness. The Event to Product-Level relatedness fields (AE_EVENTS_TO_DRG.RELATEDNESS_CD and RPT_RELATEDNESS_CD) are used if the SUBWIZ_USE_EVENT_TO_DRUG_ASSESSMENT System Parameter equals Y, otherwise it corresponds to the AE_CASES.CO_ASSMNT_RELTD_CD or REPORTER_CAUSE_TYPE.

■ M: Medically Confirmed. This element corresponds to the Medically Confirmed Flag (AE_CASES.EV_MED_CONF_FLAG).

■ O: Overdose. This element corresponds to the Overdose Flag (AE_CASES.OVERDOSE_FLAG).

■ P: Study Procedure. An adverse event that was caused by the study procedure or clinical trial (and not the drug) is now reportable. This element corresponds to the Study Procedure Flag (AE_CASES.STUDY_PROC_CAUSED_AE_FLAG).

■ C: Event occurred in the same country as being reported. If the agency has a country list associated with it, then the rule extends to all countries in the list.

■ Event List: The name of a TMS Special Search Category. MedDRA includes a number of Special Search Categories (SSC) that can be used, or, using the TMS Repository Maintenance function, you can build your own lists. This feature is useful in supporting reporting requirements that are based on lists of adverse events, such as Infections for the MHLW or the emerging US and EU standards for "always expedited" cases.

The following operators are supported:

■ AND: is implied with two tokens occurring in sequence (e.g. SU is Serious AND Unexpected).

■ +: OR. For example: S+U is Serious OR Unexpected.

■ -: AND NOT

■ (): Nested logic. Parentheses are evaluated from the inside out. For example S(U+R) is Serious and either Unexpected OR Related)

Setting the case data level of reportability criteriaThe reportability criteria for Seriousness, Expectedness, and Relatedness can be controlled either at the Case level or at the lover levels in the data model (Event or Event-To-Product). This is set system-wide in the controls table.

To set the level for reportability criteria:

1. Log on to Oracle AERS and a system administrator with access to the System Parameters tab.

2. Open the Administrator Console and select the System Parameters tab.

3. Update the Control value for the SUBWIZ_USE_EVENT_TO_DRUG_ASSESSMENT control. Set the value to Y to perform the assessment at the lower level (Event-level seriousness, event-to-product expectedness/relatedness), or N to use case level criteria.




Creating or modifying a Reportability Rule TemplateOracle AERS allows you to create basic templates for reportability rules, then apply those rules to your approval records. It is recommended that you maintain at least the basic reportability rules as templates to facilitate maintaining the approval-level rules.

To create or modify a Reportability Rule Template:

1. Log on to the Global Maintenance subsystem as a user that has access to the Reportability Rules tab.

2. Select the Rpt Rules tab.

The Reportability Rules Template screen displays.

3. If you are refining a rule for an existing agency/license type, make your changes.

4. If you are creating a new rule, click the Add Record button or select Edit=>Add Record.

5. Specify the reportability rule following the syntax outlined in the section above (Reportability Rule Syntax).


Applying a Reportability Rule TemplateYou can apply the reportability rules templates to your approval records at any time. You may want to do this when you have added new product approvals, or if you have added new rules or updated existing rules.

To apply a template:

1. Log on to the Global Maintenance subsystem as a user that has access to the Reportability Rules tab.

2. Select the Rpt Rules tab.

The Reportability Rule Template screen displays.

3. Highlight the record containing the rule that you want to apply.

4. Press the Apply Rules button.

Oracle AERS prompts you to confirm that you want to apply the rule template.

5. Press OK.

The matching product approval records are updated.


Note: The templates support a wild card in Agency and License Type. This allows you to create very broad rule templates. This is a convenient feature, but you must use caution when applying these templates as they impact a large number of approval records.

Note: When you Apply a template, all existing reportability rules for the matching Agency/License are over-written. You cannot undo the action.

Maintaining Agency Reports


Managing individual reportability for an ApprovalThe Reportability Rules Templates are useful features when initially setting up your environment or for applying wide-spread changes to existing reportability rules. However, you may have very specific requirements for a particular product, or for that matter, a particular license agreement. In these cases, you can individually update the reportability rules for the specific approvals impacted by the specialized rules.

To update a specific reportability rule for an approval:

1. Log on to the Global Maintenance subsystem as a user that has access to the Products tab.

2. Select the Products tab.

The Company Products screen displays.

3. Select the Product whose reportability rules you want to update.

4. Select the Approvals sub-tab.

The Approvals for the Product displays.

5. Highlight the specific approval record that you want to update and press the RPT button on that row.

The reportability rules, for that approval, if any, are displayed.

6. Update the existing rules or insert new ones if they do not already exit.

7. Click the Save button, or select File=>Save, to save your changes. and close the window.

Maintaining Agency ReportsAn agency record in Oracle AERS corresponds to a regulatory agency or geographic location and its corresponding regulatory report. You must define an Agency/Report for Oracle AERS to determine reportability or track a submission. An agency does not need to correspond to a formal regulatory authority. You can use it generally and flexibly to correspond to any entity that receives a formal submission. For example, an agency/report could be 'ZIMBABWE/CIOMS I' if you track the generation and transmittal of a CIOMS I report to a local operating unit in Zimbabwe, Africa. For countries with local regulatory reports (e.g. BfArM report for Germany) there is a record corresponding to the general report (e.g. CIOMS I) as well as the local report (BFARM).

Note: Unlike the template, each of the reportability types is represented on its own row. You should only have ALE, EXP, and PER records here, though you do not need all three, only those that apply. For example, if there is no “alert” submission associated with that agency, then you would only have EXP and PER records associated with that approval.

Note: You can perform agency maintenance using the Oracle AERS Global Maintenance subsystem.



Adding Agencies/ReportsTo add an agency/report:

1. Select the Agencies tab from the Global Maintenance subsystem.

The Agency Maintenance screen displays.

2. Click the Add Record button or select Edit=>Add Record.

3. Key in all fields. See AGENCY_REPORTS table definition for details on the fields.


The Agency is saved to the database.

Updating and deleting Agencies and ReportsTo update an agency or report:

1. Select the Agencies tab from the Global Maintenance subsystem.

2. The Agency Maintenance screen displays.

3. Select the Agency you want to update.

4. Key in the appropriate fields.


The system saves the change to the database.

To delete an agency or report:

1. Select the Agency you want to delete.

2. Click the Delete Record button.

The Agency disappears from the screen.


You do not receive a prompt. The Agency is deleted from the database.

AGENCY_REPORTS table definition

Field Data Type Notes

IN_USE Character The Active Flag indicates that you are actively reporting to this authority using this report form.

AGENCY Character Clients can choose any arbitrary identifier for the agency. Oracle recommends using the country codes to represent the agencies. Note, the agencies used here must match the agency used to track approvals.



LIC_TYPE Character, limited to valid license types

License Type is used if the reporting form is specific to a particular license type. You only need to enter this field if you have multiple records for the same agency. For example, the US FDA has separate reporting rules for NDA and IND and by distinguishing between the two in this table, you can define separate reporting rules and track submissions to these licenses separately.

REPORT_FORM Character The Report Form used to track the report. The values used here must match the values for the REPORT_ FORM parameter passed to the report program

LOCAL_FORM Character, Y/N (Check box)

Check this box if this report form is a local report form for the agency. If this box is checked, this report form is selected by the submission wizard if the Country Where Event Occurred matches the Agency. Examples of local report forms include the MedWatch for the US FDA, the VAERS, BfArM, Yellow Card, and CERFA.

FOLLOW_UP_REQUIRED_FLAG

Character, Y/N (Check box)

This flag is used to indicate the report forms that require follow-up submissions in the event that the data changes. In a typical configuration, only standard expedited report forms (such as CIOMS I, MedWatch, etc.) has this flag set.

PROGRAM_NAME Character The AERS Program Name for the report that is run to satisfy this reporting requirement.This feature is not utilized in AERS 4.5 but is used in the future to further automate reporting.

REPORTABILITY_TYPE

Character (ALE, EXP, PER)

The Reportability Type for the Agency/Report. This is a critical field for the Submission Wizard.

PRODUCT_TYPE Character (DRUG, DEVICE, VACCINE)

The product type that is reported using the report. Enter the appropriate product type if the report form is used specifically for a single product type, such as VACCINE for the VAERS reports. If the report is used for multiple types (such as the CIOMS I for drugs and vaccines), this field should be left blank.

DURATION_DAYS Integer For expedited reports, the number of days from when the company is informed of the adverse event until the report is due. This field is used by the Submission Wizard to calculate the Due Date for the report.

PERIODIC_INTERVAL

Number, in months The number of months for the periodic reporting interval. Used in combination with the Birth Date to calculate the periodic report due date.




SUBMISSION_VALIDATION_PROC

Character The Name of the Submission Validation Rule:

RULE1: Enforces unique license number/agency combinations,

RULE2: Allows multiple entries per agency, uniqueness within Drug

TRACK_SUBMISSIONS_PROC

Character The Name of the Submission Validation Rule:

RULE1: Creates one submission tracking records for each unique license number/agency combinations,

RULE2: Creates a single submission tracking record per agency

RULE3: Creates a single submission tracking record for the Drug List being used to generate the report (usually reserved for PSUR reporting)

COUNTRY_CD Character, optional The country of the agency

MASS_SUBM_CANDIDATE_FLAG

Character, Y/N (Check box)

Indicates whether the agency/report combination should be checked by default in the Case Browse Update Submission Mail Dates function.




Oracle AERS dictionary architecture 19-1

19Oracle AERS dictionary architecture

Dictionaries of controlled terminology are a basic requirement for adverse event reporting. AERS is distributed with a standard dictionary implementation that includes these requirements. For a variety of reasons you may need to extend, modify, or completely replace the standard implementation. The purpose of this chapter is to provide the necessary information to customize the dictionary implementation. This chapter contains the following sections:

■ Overview of AERS Dictionary Functionality

■ AERS Dictionary API Definition

■ AERS TMS Interface Module

Overview of AERS Dictionary FunctionalityThe regulatory requirements for adverse event reporting dictate that the same information needs to be reported using different terminology, depending upon the report and the indented recipient. For example, if an adverse reaction to a drug that must be reported internationally occurs in Germany, the local German BfArM report identifies the drug using the German trade name, the MedWatch report to the FDA must use the US trade name, the international CIOMS report includes the generic name, and the E2B report uses the German trade name and the list of active substances using non-proprietary names.

The approach that AERS takes is that you enter a single verbatim term. AERS automatically searches the dictionary for a match. If it is found, AERS stores a link into the dictionary along with the verbatim term. Subsequent AERS reporting and search processes make use of this link to find the appropriate term or terms. If a dictionary match is not found, the term is flagged as unmapped. There are batch and interactive tools for resolving unmapped terms.

Dictionary ColumnsA subset of the fields in the AERS case data is defined in the data model as dictionary columns. When data is entered in a dictionary column and the term is classified, AERS stores data in cluster of several database columns that are related to the dictionary column. The database columns are Reporter Verbatim, Company Verbatim, Dictionary Term ID (or TID), the Unmapped Flag, Dictionary Version (or DID), DomainID, and Term ID Timestamp (TID_TS). In addition AERS will stores the Meddra higher level terms defined in the dictionary at the time the dictionary field is coded.

The basic behavior in AERS is that the reporter verbatim is entered by the user (or automated import function), the value is copied into the company verbatim field, and then AERS uses the dictionary interface to try and classify the term. If the term

AERS Dictionary API Definition


successfully maps to the dictionary, the values for the remaining three fields are set by the dictionary interface.

AERS, Dictionary Management, and TMSAERS was designed with the idea that dictionary management is an outside service that may be used by several applications. The AERS dictionary API isolates the AERS code from the actual implementation of the dictionaries. It allows you a great deal of flexibility in how your dictionaries are implemented. The AERS architecture treats the dictionaries as separate cooperating applications. There is a well defined interface between the core AERS software and the dictionary. The core AERS software does not care what dictionary management software is used or how the dictionaries are structured, as long as the requirements of the API are met. This separation allows a large degree of flexibility in how you implement the dictionary function. It allows a you to share the dictionaries that AERS uses with other applications such as Oracle Clinical and to meet the requirements of all the applications.

AERS is distributed with embedded restricted TMS licences and includes the AERS standard implementation of the dictionary API for TMS. The AERS installer has an option to install AERS compliant dictionary definitions in TMS and scripts to load these definitions with WHO Drug and MedDRA data. These components constitute the AERS TMS Interface Module. This module allows for a fast implementation of AERS when only basic dictionary services are needed and provides a starting point for you if you need a customized dictionary interface.

AERS Dictionary Related FunctionsThe following list describes the AERS functions:

■ Case term classification

■ High Level Term Reporting

■ Dictionary Queries

■ Derived Unexpectedness

■ Omissions

AERS Dictionary API DefinitionThis section contains the definition of the AERS Dictionary API. All interactions between AERS and the Dictionary System (DS) go through this API. The API is defined by the AERS data model and the specifications for a set of database packages, views and Oracle Forms. Because it is useful to understand how AERS behaves on its side of the API, this section is organized by the major functions within AERS.

The required components of the AERS Dictionary API are:

■ AERS_DICTIONARY_API package

■ Dictionary reporting DE, DH, DDE, and DDH views

■ Dialog box for dictionary search switches: q_dictlk.frm

■ Omission management form: tms_mlscl

Note: Oracle does not guarantee that the API will not change in future releases of AERS.



■ Dictionary content V views

■ Derived Unexpectedness DU Views

The following elements constitute a layer between most AERS programs and the API. They can modified to improve performance.

■ AERS_DICT_FUNCTIONS package

■ AERS_DICT_FUNCTIONS2

Dictionary Interface Data ModelA subset of the columns in AERS case data are dictionary columns. In the AERS data model there is a reporter and a company verbatim column for each adverse event or diagnosis term. The default behavior in AERS is that when new data is entered in the reporter verbatim field, the contents are copied to the company verbatim column. The company verbatim column is a dictionary column. The drug name columns in case data are all dictionary fields. The drug name columns are single columns and are not paired reporter and company names.

Every dictionary column in the AERS case data tables is accompanied by a set of dictionary support columns. When the term is classified, the API returns new values for these columns, and AERS stores these values in the row with the term. Subsequent reporting and search functions use these columns to find the required dictionary data.

DefinitionsTID: The Term ID is an ID for the term assigned by the DS. The TID is used in AERS to join to data in the DS. AERS does not assume that the TID has any intrinsic meaning.

Unmapped Flag: If classification fails, the unmapped flag is set to ‘Y’. The AERS reports often have specific requirements for handling unmapped terms. The unmapped flag is also used in AERS workflow to find cases that contain omissions.

Dictionary Version: This is the version of the dictionary that the field was classified against. For MedDRA fields it should be in the standard MedDRA format, e.g. “5.1”.

DomainID: The dictionary domain that the term was coded against.

TID_TS: The Term ID Timestamp is the GMT adjusted timestamp at the time the term is classified. For MedDRA terms, AERS stores the MedDRA LLT, PT, HLT, HLGT, and SOC at the time the term is classified.

Dictionary Version Support and DomainsAERS supports multiple active versions of the adverse vent and diagnosis dictionaries.This feature allows you to freeze the dictionary version that is used to classify the terms for the cases for a specific drug or study. The frozen version of the dictionary is associated with a domain. As a default AERS uses the LATEST domain when it classifies terms. AERS automatically sets the domain that will be used for a case when the product code, study, and case type are entered or changed. Since the product code is derived from the drug name, AERS does not extend the use of domains to classifying drug names.

SetDomain FunctionPurpose: This procedure sets the active domain based upon three key case data fields. This procedure is called from the AERS data entry module when any of the three values that determine the domain are set. This is usually before any diagnosis or adverse event terms are entered.



The return value indicates the case contains (or may contain) any classified field that may need to be reclassified because the domain changed. The return value of one indicates the case data will need to be reclassified. A return value of zero indicates that the data will not need classification.

If this function returns a one when called from the AERS data entry front-end, the front end will post all pending data and call ReClassifyCase.

Specification:

function SetDomain (pCaseID in ae_cases.case_id%type,

pCaseType in ae_cases.case_type%type,

pProdCD in ae_cases.drug_project%type

pStudyID in ae_cases.study_id%type)

Return pls_integer.

GetCurrentDomainFunction FunctionPurpose: This function is used to obtain the ID of the active dictionary domain. It enables the application to echo the active domain to the user. It may be used in AERS to display the current domain for the user.

Specification:

function GetActiveDomainID return pls_integer;

V_DICT_DOMAINSThis view is used by AERS to display a pick list of available domains. AERS selects distinct domain_id, name.

Classification

Interactive The AERS front end data entry module calls ClassifyTerm in the When_Validate_Item trigger. Classification is also invoked during an E2B import. It uses values in the out parameters to populate the dictionary support columns, TID DOM_ID, etc. If the term fails to classify, it calls GetLastOmissionKey to get the parameter values to use when to call the omission management form, named tms_mlscl. If the form returns a VT, either the same or a different term, AERS will try to classify the term again. In this case the term should classify.

AERS calls the API functions whenever the content of a dictionary field is deleted or changed, the effective domain for a case changes, or the values passed to classify terms change. This allows the dictionary management system to keep a record of the terms that have been classified with a link back to each row and column where the terms appear in AERS. This is key feature in TMS full integration.

Column Name Data Type0 Purpose

Domain_ID Number The internal ID number of the domain.

Name Varchar2 The external name of the domain presented to the users. It should be unique.

BASE_DICTIONARY_ID

Number This column is not used by AERS.



The following table shows the triggering action and the API function that is called.

E2B importThe E2B import creates and updates AERS cases. Just like manual data entry, the E2B import classifies terms as they are stored in the AERS database. The E2B format allows the sender to use MedDRA code numbers rather than text terms and to send a list of active substances and leave the drug name blank. Because AERS requires text terns for these fields, the dictionary API classify functions are required to return the correct terms for storage in AERS.

ClassifyProduct FunctionPurpose: This function classifies a drug/product term. It is similar to ClassifyTerm. The difference is that it only classifies product names and it implements a special lookup used in E2B imports. In an E2B message, a drug may be identified by a trade name and/or a list of active substances. This function searches the dictionary for a match on any combination of these data elements.

Specification:

Function ClassifyProduct (pTerm in out varchar2,

pTableName in varchar2,

pColumnName in varchar2,

pTID out number,

pDomID out varchar2,

pUnmappedFlag out varchar2,

pPK1Value..8 varchar2 default ‘0’

pActiveSubstances in table of varchar2(100))

Return plsql_integer;

If the term is null and the active substance list is not empty, use the new TMS functions to look at the preferred name. First use TMS_USER_EXTERNAL.GetIDviaTerm to find the IDs for all ingredients. The level ID for ingredients is stored in the controls table. Then call GetCodingLevelTerm to get the preferred name.

Then call TMS_USER_FULLAUTOCOADE. ClassifyTerm. Finally, compare the list of Active substances with the list in V_INGREDIENTS.

Parameters:

Trigger Function Called

Database on delete row trigger DeleteRow

The Case ID changes RenameCase

The term value is changed to null ClassifyTerm

The Domain Changes ReclassifyCase

Note: This logic will not work with the new WHO Drug schema.



Return Value:

Batch ReclassifyBatch Reclassify calls classify term for every dictionary term in a list of cases. Batch Reclassify is implemented as an Oracle report that the AERS users executes as needed, from the Reports subsystem. The Oracle report is a part of the AERS core code. It calls the Batch Reclassify API procedure.

BatchReclassify ProcedureBatchReclassify filters the cases for reclassification. It locks each case in turn, calls reclassifycase, and then unlocks the case. Depending upon the parameters, it either reclassifies all cases in the database or the valid cases in RTEMP. When the “only updated dictionary terms” option is used, BatchReclassify uses the TMS source terms update flag to find cases that need reclassification.

If Batch Reclassify cannot lock a case, it skips over the case. It uses the AERS error logger to report the error. Errors logged this way are printed on the trailer page of the BatchReclassify report.

Name Values and Purpose

PTerm The verbatim term that is to be classified.

PUnmappedFlag The output value is stored in the unmapped flag column associated with the verbatim column.

pTableName and pColumnName

The values will be the AERS base case data table and column names. These parameters serve a dual purpose. They enable the implementation to control which dictionary is assigned to which AERS field. They also allow for full TMS integration.

pCaseID and pPK1..8 These are values for the primary key columns in P_TABLE_NAME and identify which row the term appears in. They will be in the same order that the PK is defined.

PTID This is a numeric identifier of the term. If the implementation uses domains, the dictionary database should be able to derive the Domain ID from this value.

pDomID The domain that was used to classify the term

pDID The dictionary version. Not Required

pActiveSubstances The list of active substances. This list is not ordered.

Usage Notes: This function works in three different ways depending on the whether the term and active substance list parameters are supplied.

Value Meaning

-1 The term classified but the list of substances did not match the list in the dictionary. If implemented, the DS will create a source term.

0 The term or list of substances classified. If implemented, the DS will create a source term.

1 The term or list of substances did not classify. If implemented, the DS will create an omission.



Specification:

procedure BatchReclassify (pqid process_queue.queue_id%type,

preasoncode varchar2,

pOnlyDictionaryChanges varchar2,

pAllCases varchar2,

pCasesClassified OUT pls_integer,

pTermsClassified OUT pls_integer);

Parameter:

Reporting and High Level Term DerivationThe underlying mechanism that AERS programs use when they need to classify high level and related terms is the V Views. This is a set of views that can be joined to AERS case data using an outer join on the Term ID (TID) and Domain ID (DOMAIN_ID). The Domain ID is the domain that was used when the term was classified. AERS does not really care what the underlying structure of the dictionary is, as long as the V Views return the expected number of rows and required values. Except where noted, the V Views in this section should always return one row for each TID/DOMAIN_ID pair.

The AERS Reports, Front End, and other application programs use the D Views to obtain the high-level classification for terms in the case data. The D Views use the following naming convention:

■ DE: The current dictionary data used in the front end and submission wizard.

■ DH: The historic audit trail data used in single case reports.

■ DDH: The historic data used for r aggregate reporting by primary SOC. This view is used in the PSUR.

■ DDE: This is the same as the DDH, but for current data. Specifically for use in ad hoc reporting.

The D Views contain dictionary data and are defined for each table in AERS. The D Views return a row for each row in the AERS case data, even if the terms are not mapped.

The D Views contain the columns needed by AERS Reports. These change when new report functionality is added.

In addition, the API contains some V Views. These views are used when the application needs dictionary data out of the context of the case data.

Name Values and Purpose

pqid The QID of the report

preasoncode A reason code is required when the case is locked.

pOnlyDictionaryChanges

If pOnlyDictChanges is set to ‘Y’, only fields that are affected by dictionary changes are updated. This flag is typically used after an update to the dictionary is made, such as accepting new verbatim terms or installing a dictionary upgrade.

pAllCases Ignore rtemp and reclassify all the cases in the system.

pCasesClassified Returns a count of the number of cases reclassified.

pTermsClassified Returns the total number of terms reclassified.



The AERS DE and DH Views join the AERS case data to the V views. The D views are reference by most AERS reports and programs. The D views are not a formal part of the API. However, some V View implementations have neccessitated D View changes to optimize performance.

The AERS_DICT_FUNCTIONS package contains a set of functions and procedures that return high level dictionary terms for display by Forms programs.

V_ACTIVE_SUBSTANCESThis view returns the list of active substances for a drug. It is used to populate the active substance list in the E2B report. These should be non-proprietary or experimental names. This view returns the list of active substances for a drug. The E2B report will use the preferred name as an active substance if this view returns no rows for a drug.

V_SPEC_CATYou can define named lists of event terms in the dictionary. In MedDRA these are implemented as customer defined special categories. These list are used in AERS functions such as the Submission Wizard. This view returns one row for each list that the term, identified by the TID/DOMAIN_ID pair, links to.

AERS Dictionary QueryAn AERS query makes use of links in the dictionaries through several components. To start a dictionary search you invoke a dialog box, which is launched from the AERS user interface with a “call form”. The dialog box collects the dictionary search parameters. These are stored by AERS as part of the query definition. Each dictionary field in the query uses a different set of dictionary query parameters. You may replace

Usage Notes: The V Views supplied during the AERS installation may contain more columns than specified here. These columns were added for testing purposes and are never referenced in AERS code.

Column Name Data Type Purpose

TID Number The Term ID returned when the term is classified.

Domain_ID Number The Domain ID that was active when the term was classified.

AERS_PRODUCT_TYPE

Varchar2 This field is in the view because of its potential to support drug device combo products.

Substance_Name Varchar2


TID Number The Term ID returned when the term is classified.

Domain_ID Number The Domain ID that was active when the term was classified.

SPECIAL_CATEGORY Varchar2

SPECIAL_CATEGORY_CODE

Number



the standard dialog box with one of your own design. When the AERS Query infrastructure runs the query, it adds a pipeline function to the “from” clause for each dictionary and the appropriate joins to the “where” clause. The parameters gathered in the dialog box are passed to the pipeline function. The AERS API for dictionary searches is defined as a specification for the call to the form and the pipeline function.

There are a fixed number of search parameters available. Some have a fixed meaning and some may be defined by the implementation.

Dictionary Pipeline FunctionWhen an AERS query uses a dictionary query, AERS adds the pipeline function using a table phase in the from clause. AERS adds as many table phrases as there are dictionary fields in the query. The query joins the case data using the TID and DomainID pair.

The output of this function is a set of TID and DomainID pairs that match the criteria passed in the parameters. Depending upon the implementation the list may include the TIDs for all verbatim terms or just those used in AERS data.

Function:

This function is defined in the dictionary API package.

Function Search (pTableName varchar2,

pColumnName vachar2,

pTerm varchar2,

pStartLevel varchar2,

pHighestLevel varchar2,

pUseContext AERS_FLAG,

pUsePreferredLinks AERS_FLAG,

pDomainID varchar2,

pUDparam1..10 varchar2)

returns DictSearchSet pipelined

The AERS query pipeline function is a wrapper for the TMS tms_sapi_vt.queryVTS function.

Parameters:

AERS Parameter Notes

pTableName The AERS table name of the dictionary verbatim field.

pColumnName The AERS column of the dictionary verbatim field.

pTerm The string to match. How it is matched depends upon the setting of the flags.

pStartLevel The search will look for terms matching the search string at this dictionary level.

pHighestLevel The search will go up to this level and then down to children finding all the cousins of the search term. If null, the search will only go downward.

pContextSearchFlag Use context searching.Y/N



Dictionary Search Dialog BoxFor historical reasons the user controlled parameters to the dictionary search function are called the switches. When the AERS Query subsystem needs you to enter values for the switches it uses a call form to launch this dialog box. This option is available when the DATA_TYPE in the FIELD_ARRTIBUTES table is ’DIC’.

The job of the switch dialog box is to update a database package variable named CaseBrowse.vDictQueryText with values chosen by the user. This variable contains an SQL Boolean expression that will be ANDed into the where clause of the query. The job of the dialog box is to update this fragment with the values for the switches chosen by the user. The original text for the SQL fragment comes from the AERS FIELD_ATTRIBUTES table.

The name of the dialog box form is Q_DICTLK.

The input parameters to the form are:

■ Table _name

■ Column _name

■ pTerm

Derived UnexpectednessIn AERS drug labeling, information can be stored in the dictionary and used to derive the unexpectedness event and drug combination for a core label and each licence defined in drug approvals. The derived unexpectedness is accessed by reports and the Submission Wizard using views. The AERS drug approvals and company drug table contains columns for the label and label version. The label name and label version should match data contained in the dictionary. The job of these views is to derive the unexpectedness for event term in the case based upon the label name and version. The views combine the derived unexpectedness with case data in the AE_EVENTS_TO_DRUGS and AE_LOCAL_UNEXPECTEDNESS tables. The views should return a row for each possible derived unexpectedness value even if there is no row in these tables.

The views come in both current data and historic flavors. The prefix DU is used for current data. The DUH prefix is used for historic data. The historic views can have independent dates for the case and label data. This can be very useful in PSUR where the label date might be the end of the period and the case data as-of date might be the date that all data is finalized. The label date column in HIST_VIEW_TS is set by reports.

AERS includes a label maintenance form and two tables, PRODUCT_LABLES and LABEL_VERSIONS that support the definition of labels and their versions. These components are not considered part of the API. These may need to be replaced if the customer wants to change the Dictionary implementation of labels.

pUsePreferredLinks Use the preferred path or links when going up or down.Y/N

pDomainID Return VTAs for only the given domain. Using this option will exclude AERS cases that were classified using other domains.

pUDparam1 The user defined parameters are dependent on the features supported in the dictionary.

AERS Parameter Notes



Dictionary Content ViewsThere are a few tables in AERS, outside of the case data, where dictionary terms are stored. For example, the drug labeling table lists the MedDRA terms for possible adverse reactions that appear on the drug label. Currently in AERS these columns are not classified. Rather, the data entered in the fields is validated against the appropriate of dictionary content views.

V_MEDDRA_TERMSThis view creates a flat list of MedDRA preferred terms in a domain, only with the primary HLT, HLGT and SOC. This view returns one row for each preferred term in the dictionary. The first purpose of the view is to provide an LOV of PTs. These are used in the drug labeling tables. This view joins other AERS data using MedDRA codes, as these are generally stable through releases.

V_PRODUCT_NAMES This view returns a list of all product names in the drug dictionary that are valid for data entry.


Domain_ID Number The Domain ID is used to pick the dictionary version.

PT Varchar2 The preferred term

PT_CODE Varchar2 MedDRA code

PT_UPPER Upper case. Indexed for performance

HLT Varchar2 High level group term in the primary path

HLT_CODE Varchar2 MedDRA Code

HLT_UPPER Upper case

HLGT Varchar2 High level group term in primary path

HLGT_CODE number MedDRA code for hlgt

HLGT_UPPER Varchar2 Upper case

PRIMARY_SOC Varchar2 System organ class on the primary path

PRIMARY_SOC_CODE

Number Soc MEDDRA code

PRIMARY_SOC_UPPER

Varchar2 Upper case

Column Name Data Type Notes

PRODUCT_NAME Varchar2 The drug names in this view should be unique.

PRODUCT_NAME_UPPER

Varchar2 Indexed for performance.

LEVEL_NAME Varchar2 A short name for the level. This value is only used for display to the users and has no meaning in AERS.

AERS_TYPE Varcahr2 The AERS product type.

AERS TMS Interface Module


V_REGULATORY_GROUP_NAMESThis view returns a list of all regulatory group names in the dictionary. It is used to validate the COMPANY_DRUGS table.

AERS TMS Interface Module This section describes the implementation of the AERS/TMS Integration Module. The interface module is a fully tested and validated AERS component. It supports all AERS dictionary related functions. The purpose of this section is to provide the information you need to modify the module. A common reason that you will need to modify or reuse components of this module is to share the dictionaries used by AERS with another applications. The AERS TMS implementation may not satisfy all the requirements of the other applications.

The interface module implements a full TMS external application integration. When full integration is used, TMS stores a record of every omission and every classified term. This allows a a TMS user to query and view data in the source application. It also permits TMS to notify the application when a change to the contents of the dictionary will effect the data in the application, and that reclassification is necessary.

Full integration also allows workflow control of omission management between TMS and the application. Workflow integration is not implemented in the current AERS release.

The AERS TMS interface module is more than an implementation of the AERS API. It contains the following additional components:

■ Scripts to define the AERS standard MedDRA and WHO Drug Dictionaries in TMS.

■ Scripts to load and update the dictionaries using the vendor supplied data.

■ An implementation of the TMS HTML and Form drill down functions that enforce AERS security.

■ Scripts to add the AERS Validation Drugs to WHO Drug.

■ Features in the AERS installer to create and load TMS dictionaries and define AERS as an external application to TMS.

■ TMS data migration scripts that move dictionary definitions and contents from one TMS instance to another.

The source for database portions of the TMS Interface Module is available. It is loaded to a disc in the aers/database folder in OPAHOME by the AERS server installation. The following table show the locations of the various components.


NAME Varchar2 The drug names in this view should be unique.

NAME_UPPER Varchar2 Name in upper case. Indexed for performance.

AERS_TYPE Varchar2 The AERS product type.

Module Path

Dictionary Creation and Load Scripts aers\database\configuraation\tms



AERS Standard Dictionaries in TMSAERS is distributed with a set of TMS dictionary creation scripts that implement a WHO drug and MedDRA dictionary, and dictionary load scripts that load the standard WHO Drug and MedDRA data into these dictionaries. The AERS /TMS Interface module and companion configuration data are designed and tested to work with this model.

The following describes a high level definition of how the dictionaries in the standard model are defined:

■ The AE dictionary is a standard MedDRA dictionary, implemented as a preferred path dictionary.

■ The drug dictionary is WHO Drug, with new levels for regulatory group names, products, and company product names.

■ The Diagnosis terms dictionary is the same MedDRA dictionary used for adverse event terms. In some areas in the API and user interface it appears as a separate dictionary but it is mapped through metadata to MedDRA.

■ To reduce its dependency on any specific model, the AERS / TMS interface module is metadata driven.

■ The product labels dictionary defines the labels used for derived unexpectedness. Each label name is a term in this dictionary. Named relations are used to link Meddra terms in the AE dictionary to the label.

AERS enhancements to WHO DrugThe AERS standard drug dictionary is WHO Drug with extensions. From the user’s perspective, these extensions provide the following functions:

■ Non drug products can be added to the dictionary without forcing their terms into the WHO drug constraints. You may add your own high level terminology for devices.

■ The new model can identify the AERS product type, DRUG, VACCINE, or DEVICE, for a product.

■ The AERS level Regulatory Group Name allows you to define a link to AERS company drugs, without changing the WHO Drug preferred name.

■ The new AERS level Company Product Name allows you to define names that include more information than what is captured in a WHO Drug trade name.

■ Blinded therapy and placebo are now attributes of the name stored in the dictionary.

Regulatory Group NameThe Regulatory Group Name is used as the link into the AERS COMPANY_DRUG table. The company’s drug database in AERS links to drug approvals and is used to derive the AERS product code. In earlier AERS old data model, this function was

API packages aers\database\schema\is\ppf\aers_dictionary_api*b.sql

aers\database\schema\is\ppf\aers_tms_access_*.sql

API vies aers\database\schema\is\viiews\v_*.sql.

Module Path



performed by the preferred name. This usage of the preferred name created the following problems:

■ If there is more than one manufacturer for a drug, the data model could not distinguish company drugs from other manufacturer’s drugs.

■ Two company products with the same generic name must be distinguished for regulators. For example the two drugs could have different indications.

Any coded term, that is a company drug, should link to one Regulatory Group Name. If the drug is not a company drug, it should not link to a regulatory drug name.

You may choose not to use the Regulatory Group Name and instead use the preferred name for this function. If you choose this path you will need to use an alternate implementation of the V_DRUG view.

Company Product NameThe Company Product Name is an additional coding level for product names. It is used for names that do not fit comfortably into the WHO Drug trade name level. There are several common reasons for this:

■ The product is a medical device

■ The company needs to capture names that are more specific than what is usually included in WHO Drug. This is very common for biologics.

■ The drug must be reported in the trade name field of an E2B report, which is limited to 70 characters.

■ A Company Product Name may be linked to higher-level drug names in several ways. All the links are optional because the product may not be a drug or a vaccine.

■ If the product is a drug or vaccine, it is linked to a WHO Drug trade name.

■ The Company Product Name may link directly to a Regulatory Group. If this link exists, it is used to derive the regulatory group. The trade name may link to a different regulatory group.

■ The preferred name is always found using the trade name link.

Additional Attributes

The AERS WHO Drug implementation makes use of the TMS values associated with each term. The Who Drug data load populates these values.

Attribute Name TMS column Notes

WHO Designation Value1 This is the designation code from WHO Drug. It is not used by AERS but it is commonly used by TMS customers.

Number of Ingredients Value2 This is the number of ingredients in WHO Drug.It is not used by AERS but is commonly used by TMS customers.

AERS Product Type Value3

Blinded Therapy Type Value4 P is Placebo, B is Blinded Therapy, and Null or N is a normal drug.



AERS Enhancements to MedDRAAERS uses the common primary path TMS implementation of MedDRA. This is necessary because the international standard for periodic reporting is that adverse events must be summarized by the primary MedDRA SOC. The primary path implementation also allows AERS to perform dictionary searches using the primary HLT and HLGT for a preferred term. In this implementation, the only addition to the standard implementation of MedDRA in TMS is to add the dictionary version as an attribute of the dictionary. You need to update the attribute whenever a new version of MedDRA is loaded into TMS.

Reporting view modesThere are two different schools of thought about when the high level Meddra terms used in reporting should be derived. The AERS TMS module allows the customer to desired with mode to use by choosing the from two set of dictionary reporting views.

Classic ModeClassic mode is so named because it was the only rule supported in AERS for the first six years. In classic mode, the high level terms are derived at the time they are used using the current mapping of the verbatim term in the domain that the term was classified against.

Clinical Compatibility ModeClinical Compatibility Mode (CCM) uses the dictionary summary terminology that is stored in the case data for displaying and reporting purposes, rather than displaying the summary terminology dynamically from the dictionary, as in Classic Mode. When using CCM, the summary terms that print on the MedWatch and CIOMS reports are the values that are stored in the case at the time the terms are classified or reclassified. In Classic Mode, the summary terms that would be displayed and used for reporting would be the terms included in the most current state of the dictionary. For PSUR reporting the CCM DDH views derive the PT and SOC using the links in the latest dictionary version from the LLT stored in the case data.

CCM ExampleA case is entered that maps to the "latest" MedDRA version installed. For the purpose of this example, let us assume this is MedDRA 6.1. The adverse event terms and indications are entered and coded against MedDRA 6.1.

Now, let us say you update the TMS dictionary from 6.1 to 7.0, so that MedDRA 7.0 is the "latest" version installed.

AERS/TMS Concept MappingThe following table displays how some of the basic AERS and TMS concepts are related.

AERS TMS Notes

TID VTA ID The VTA ID value returned by TMS is stored in the TID column in AERS tables. It is assumed that a TID only has meaning when it is used in a domain. AERS always uses the TID/DomainID pair to join to TMS data.



Interface Module TablesThis section defines tables that are used to map AERS data to TMS data. They are only used by API code.

AERS_TMS_DICTIONARY_COLUMNS TableWhen a dictionary API function is called in AERS, it passes the AERS table and column name as input parameters. This table is used to look up the information needed to pass on the request to TMS. The table has one row for each AERS dictionary column. The number of rows is fixed for any given version of AERS.

DID An informative note of the dictionary. This attribute is defined in the TMS seed data with the short name ~DICTVER

This is an attribute of a dictionary defined in the standard AERS model. When you load new MedDRA data, they must update this attribute

Domain Domain In the TMS integration module AERS and TMS domains are the same entity. The standard model is that the latest domain is the latest view of base dictionaries. The domains used for studies, where the dictionaries are frozen, are views of virtual dictionaries that have been frozen on a particular version of MedDRA.

The AERS Schema Name

Integration Key TMS identifies an external system by the combination of an instance and the integration key. In AERS, the value of the integration key is typically ‘AERS’. To support multi-schema installs the value will be stored in the controls table.

AERS_DICTIONARY_COLUMN_ID

sourcetermid Identifies the AERS table and column name of a dictionary column.

AERS_ROW_ID occurrenceid Identifies the row in an AERS case data table that contains one or more classified terms.


TABLE_NAME Varchar2 The AERS table name.

COLUMN_NAME Varchar2 The column name of the AERS VTA text field.

TMS_DICTIONARY_ID

Number The TMS ID of the base TMS dictionary used to classify terms in this column.


Number This number uniquely identifies the AERS table.column combination and is an alternate key of this table. The value is used as the sourceTermId.

DID_COLUMN Varchar2 The column name of the DID column.

DOM_COLUIMN Varchar2 The column name of the Domain ID column.

AERS TMS Notes



AERS_TMS_TERM_ROWSThe AERS_TMS_TERM_ROWS has the following attributes:

■ It enables full TMS integration.

■ It maps AERS rows, identified by primary key values, to TMS source terms.

■ It has one row for each dictionary column in each row of the AERS base tables.

■ An insert or update occurs in the table each time ClassifyTerm or ClassifyProduct is called.

■ It can be used in both directions.

AERS Controls Table EntriesThe TMS interface makes use of the AERS CONTROLS table. The following tables lists the control ids used in the TMS interface.

UNMAPPED_COLUMN

Varchar2 The column name of the unmapped flag.

OMISSION_MGMT_OPTIONS

Varchar2 The parameter for the omission management screen that determines which of the completion buttons to display.

Column Name Data Type Usage


Number Used for performance improvement.

AERS_ROW_ID Number This value is assigned by a sequence when a row is inserted.

DOMAIN_ID Number The domain the column was last classified against.

PK1VALUE...8 Varchar2(50) The PK values from the PK AERS columns. Most AERS tables use row sequence numbers as PK values. The value ‘0’ is used in this table to when the level does not apply.

Control ID Usage

TMS_INSTANCE This value is needed in some TMS calls. The value is initialized to globals_name.global_name

TMS_XSYSTEM_KEY The is the id of the AERS application. Usually the AERS schema name is used here.

AERS_INSTANCE The instance than AERS is in stalled in. The value is initialized to globals_name.global_name

AERS_SCHEMA The AERS schema name

DICT_LATEST_DOMAIN_ID The TMS id of the default domain dictionary domain.




Notes on AERS_Dictionary_API PackageThis section contains notes on the implementation of the AERS_Dictionary_API package in the TMS interface module.

GetCurrentDomainFunction This function returns the gCurrentDomain package global.

GetLastOmissionKeyClassifyTerm and ClassifyProduct store the parameter values needed to start the omission management form in package globals. The procedure simply echoes back these values. The omission management options value comes from the AERS_TMS_DICTIONARY_COLUMNS table.

ReclassifyCaseThis procedure will circle the AERS_TMS_DICTIONARY_COLUMNS and AERS_TMS_TERM_ROWS, and using TABLE_ATTRIBUTES, create a dynamic SQL that reads all the dictionary terms in the case and calls classify term to reclassify them.

SearchThe AERS Search pipeline function is a wrapper for the TMS pipeline function tms_sapi_vt.queryVTS. The following table displays how the parameters to the TMS function are derived.

Parameter Name Derivation

pvalue1 AERS Column ID number

pvalue2 AERS Row ID

pvalue3 AERS Instance Name

pvalue4 TMS Integration Key

pvalue5 Omission option found in the AERS_TMS_DICTIONARY_COLUMNS table.

TMS Parameter Name Derivation

P_Dictionary_ID Use AERS_TMS_DICTIONARY_COLUMNS

pOrDtNullFlag Always Null

pVT Always Null

pDT The search string entered by the user

pType ‘VTA’

pSubType ‘NULL’

PUser Null

pSearchObjectId Null

pParentIds Null, AERS uses pHighestLevel instead.

pTMSInstanceName Controls table. ID is TMS_INSTANCE

pXSystemKey Controls table. ID is TMS_XSYSTEM_KEY

pSourceInstanceName Controls table. ID = AERS_INSTANCE



V View ImplementationThe V_ views are implemented using the TMS data extraction pipeline functions. These functions are in the tmesis package. The views are a prototype of the views that will be generated using the TMS data extraction view generator. This tool will be available in a future TMS release.

The views are dependent on the structure of the dictionary. The tms_dx functions take the TMS dictionary and level ID number as parameters. In order to provide acceptable performance, these must be SQL literal values in the source for the view. The AERS installer looks up the TMS IDs using the TMS short name for the dictionary levels and modifies the source for the views.

Forms Implementation

Omission Management FormThe Omission Management form in the integration module is a version of the regular TMS omission management form for use in applications like AERS, that use embedded TMS.

Dictionary Query Switches Dialog BoxThe dictionary dialog box supplied with AERS implements the subset of the parameters defined in the aers_dictionary_api.search function that perform the same functions as the switches in the pre-TMS AERS dictionary interface. The dialog box assumes that the SQL fragment includes the syntax /*parametername*/[’]value[’]. The parameter names are the same as those defined for the search pipeline function.

Drill Down ViewsFrom some TMS forms and the TMS light browser, you can drill down into the source system data. The AERS TMS Interface module includes a simple set of drill down procedures. The package is named AER_TMS_ACCESS. This package is installed in the AERS schema. This package confirms that the user connected to TMS has the necessary privileges to view AERS data.

TMS integration InstallThe AERS installation requires that TMS be installed and configured before the AERS installer is run. TMS must be installed in the same database instance as AERS. As many AERS schemas as needed may be installed in that instance, and they will all share the same copy of TMS. The AERS schemas may share or use different dictionaries.

pLanguage pUDparam1

pApproved pUDparam2

pScope pUDparam3

pInconsFlag pUDparam4

pRecordLimitn pUDparam5

pStartLevelId pStartlevel

pReverseAtLevelID pHighestLevel

TMS Parameter Name Derivation



TMS Configuration and Dictionary LoadingThe AERS installer has an option to configure the AERS standard MedDRA and WHO Drug dictionaries and load them with customer supplied data. This installer option creates a database user with the default name of TMSLOAD. A set of database packages that perform these operations are created in this schema. This schema may be left in the database after the installation is complete. The packages can be used for loading MedDRA and WHO Drug updates into TMS.

AERS Standard TMS API InstallThe AERS schema installation will install the standard API and TMS drill down functions.The API elements are needed because they are referenced by AERS programs and views. The AERS installer also runs a script called settmsconfig.sql. This script load the tables used the API and registers this copy of AERS as a TMS external applications. It uses its own schema name for the TMS DEF_INTEGRATION_KEY.

Derived Unexpectedness and Product LabelsThe AERS TMS interface module stores product labels in TMS. The derived unexpectedness views use the label data stored in TMS to compute the value of the derived unexpectedness flag. The names of the labels are stored as terms in the Product Labels Dictionary, default name short name PRODLABEL. The code allows the user to create additional labeling dictionaries. However this feature is only needed in exceptional circumstances. The expected adverse events are defined with cross dictionary links from terms in the MedDRA dictionary to the label name term. The links are created with TNS named relations, where the names are well known. If a higher level MedDRA term is linked, all of its primary path children are considered expected adverse event terms. The implementation includes a feature for qualified expected terms. This feature supports expectedness in cases where the adverse event is only expected in some circumstances such as an overdose. In this example the adverse event is unexpected when the patient receives the normal dose. The qualification is checked using addition case data. In this overdose example if AE_SUSPECT_DRUG.OVERDOSE_FLAG is Y, the event is expected. The following table provides the names for the relations and the AERS case data conditions used in the qualified label terms:

Metadata and Label VersionsThe PRODUCT_LABELS, LABEL_VERSIONS, and LABEL_MOD_REASONS are tables in the AERS schema that support labels. Each label defined in TMS must also exist in PRODUCT_LABELS. PRODUCT_LABELS includes a column for the Dictionary ID that contains the label. If necessary the customer may use multiple label dictionaries. LABEL_VERSIONS is a child table of PRODUCT_LABELS. Each version of a label is numbered. The table contains a row for each version of the label. Labels are versioned using TMS’s built in change journalling. The table contains a time stamp set to the system date just after the data is activated in TMS. The table also contains a Domain ID that can be used to identify the MedDRA version that this label version was built against. The default is the latest domain. The design decision was made not to use domains and virtual dictionaries for label versions. In a large pharmaceutical company with hundreds of products there could be thousands of label versions. The TMS user interface and queries were not designed to support this number of virtual dictionaries. The LABLE_MOD_REASONS table allows the customer to track the reason for a label change.



Label Maintenance FormThe label maintenance form is launched from the AERS Global Maintenance subsystem. The form integrates the maintenance of the AERS label metadata tables and the underlying label contents stored in TMS. The form allows the user to see the impact of a pending MedDRA update on a label. The form uses a table function DERIVED_UNEXPECTEDNESS.GETMEDDRA_ROWS to get the label content information from TMS.



Architectural details 20-1

20 Architectural details

This chapter describes three features of the Oracle AERS architecture:

■ Audit trail

■ Data model naming conventions

Audit trailCase-related tables in Oracle AERS require auditing. For each table in the set (tables names prefixed with AE_), there is a corresponding table (table names prefixed with AC_) that maintains the audit data. The system performs the audit function each time you insert, update, or delete a row in an Oracle AERS case table. Data is copied from the AE table and stored in the corresponding AC table. Each record is a snapshot of the corresponding case record as of the time it was inserted, updated, or deleted. The audit function is not user-customizable and is set up during the Oracle AERS installation.

Oracle AERS implements the audit trail mechanisms via database triggers. One exception to an update triggering the creation of an audit row in the audit table is the update of certain columns on AE_CASES that may be based on child table activity. These are the CASE_UPDATE_DT, CASE_UPDATE_USER_ID and CASE_UPDATE_SITE_ID. When these columns are updated due to a case child update, no audit row is written. The update of certain lock manager columns in AE_CASES (LOCKER_TYPE, UPDATE_SEQ_NBR, LOCK_TYPE, LOCK_GRANTOR_TS) does not trigger the creation of audit rows. Updating the AE_MOD_REASONS and AE_EXPORT_CASES tables does not trigger an audit because reasons for modification and export information are contained in the tables themselves.

A deleted case remains in the current table (as well as the audit table), with the DELETE_FLAG on both AE_CASES and AC_CASES set to True. Child rows of the deleted case reside in both the current and the audit table. When a case child row is deleted while the case is still active, the delete from the current table is physical, but rows still remain in the audit table.

In Oracle AERS, the user can control when the data is committed. The user can choose to save the data on the screen, which commits the data, or the system commits the data at the end of the case data entry session.

Data model naming conventionsThe following prefixes apply to case-related data within the data model.

No Prefix Control, configuration and list tables.

Data model naming conventions


AE_ Current case data tables.

AC_ Case audit tables.

AD_ Difference view between two versions of a case.

AH_ Historical view of AE_ tables.

DE_ Current case data view with high-level dictionary terms.

DH_ Historical case data view with high-level dictionary terms.

TE_ Derived data view pertaining to a current case.

TH_ Derived data view pertaining to a historical case.

Oracle Clinical configuration A-1

AOracle Clinical configuration

The current Oracle AERS/Oracle Clinical configuration consists of three types of integration:

■ Standard lookups of values for Oracle AERS data from Oracle Clinical tables; for example, Study, Center, and Investigator

■ "Active" lookups that return multiple data values; for example, Patient, which returns patient initials, date of birth, and sex from the Patient Positions table

■ Dynamic extract of data for reconciliation

You can configure the first two integration types through the same procedure. The third option is handled by creating cross-study data extract views that mirror the Oracle AERS staging tables.

Under most circumstances, Oracle Clinical and Oracle AERS run on different Oracle database instances, perhaps even on separate servers. To accommodate this separation, you must create a database link from Oracle AERS to Oracle Clinical. This database link should connect through the Oracle Clinical super user account.

Setting up value lookups from Oracle ClinicalOracle AERS configuration includes defining four record groups that link the main patient identifiers and copy demographic data from Oracle Clinical to Oracle AERS:

■ OCL_STUDIES

■ OCL_SITES

■ OCL_INVESTIGATORS

■ OCL_PATIENTS

In order for Oracle AERS to fetch data for field lookups, you must create a record group for reference from Oracle AERS. You define the record group with a codelist name, SQL, and a few attributes. Oracle AERS then associates the record group with the relevant fields through the field attributes.

To create each record group, follow this procedure:

Step 1: Define record group1. Connected to Oracle AERS as the schema owner, run FLD_ATTR.FMX.

2. Press the Record Group button located in the lower right corner of the screen.

Setting up value lookups from Oracle Clinical

A-2 Oracle Adverse Event Reporting System Administrator’s Guide

3. Insert a new record in the RECORD_GROUP_ATTRIBUTES table.

4. Name the Record Group. The current standard for Oracle Clinical lookups is OCL_lookup_name (e.g., OCL_STUDIES, OCL_SITES, etc.).

5. Define the codelist type. The standard is COMMON_n_COLUMN_LOV where n is the number of columns returned by the lookup.

6. Write the query. The Refresh attribute must be set to ‘Y’ for all OCL Record Groups.

7. Commit.

Step 2: Assign record groups to fields1. Query the Field Attributes form for the fields that uses the record group.

2. Assign the record group name to the codelist attribute for the field.

Step 3: Define the LOV columnsClick the Define LOV Columns button to the right of the codelist name.

A window appears showing the record group attributes and the SQL statement. The multilevel detail block should have a record for each column returned by the query. If not, create and complete the records for each column returned by the query.

■ The Column is a sequential number controlling the display order in the window.

■ The Title is the label that appears in the LOV.

■ The Size is the width, in points, displayed for the column in the LOV. For standard lookups, all columns should have a width greater than zero. For "active" (multivalue) lookups, there may be columns returned from the query that you do

Note: It is not important which field is displayed on the Field Attributes form, because Record Groups are not directly related to fields.

Note: You must assign to each column returned by the query an alias formatted as COLn, where n is the column number. Also, if you write the query externally, do not embed any paragraph returns or linefeeds in the query.

Note: Oracle AERS makes extensive use of “mirrored” fields that display the same data value on multiple screens. As it is possible to configure the system so any of these fields can be entered or updated, you must assign the record group to ALL of the relevant fields. For example, on form E_ENTRY, STUDY_ID appears twice: once in Case Login, and again on the Demographics screen. You must assign the same codelist values to all versions of a given field to ensure consistency. In addition, you should update the query form to reflect the codelist, because users can view the LOV from query as well.

Specific Oracle lookups


not need to display in the LOV, but you do want for populating fields. In these cases, set the width to zero and the column is not displayed in the LOV.

■ Return Item is the Oracle AERS field that the column populates. The value entered here is the BLOCK_NAME.ITEM_NAME from the Field Attributes table. For standard lookups, only one of the columns should have a return item. For "active" (multivalue) lookups, each column returned by the query can be assigned a Return Item name.

Once these changes have been committed, they need to be replicated to each Oracle AERS site. Under most circumstances, the changes are automatically replicated using Oracle snapshots. If the changes do not take effect at a site, verify the status of the database links and refresh as necessary.

Specific Oracle lookupsThis section describes the four record groups you must define and map to create Oracle lookups:

■ Record group for clinical studies: OCL_STUDIES on page A-3

■ Record group for centers: OCL_SITES on page A-4

■ Record group for Investigators: OCL_INVESTIGATORS on page A-5

■ Record group for patient details: OCL_PATIENTS (multicolumn) on page A-7

Record group for clinical studies: OCL_STUDIESThis section describes the definition and field LOV mappings for record group OCL_STUDIES.

Record group definition

Field LOV MappingsThe following tables contain the field LOV mappings for the OCL_STUDIES record group. Each table title lists the form, window, and item.

Codelist LOV name Codelist executable text

OCL_STUDIES COMMON_2_COLUMN_LOV SELECT STUDY COL1,

SHORT_TITLE COL2

FROM CLINICAL_STUDY_VERSIONS@ORACLIN

WHERE LIVE_STUDY_FLAG = 'Y'

Table A–1 E_ENTRY, Demographics, STUDY_ID

Column Title Width Return Item

1 Study 200 AE_CASES.STUDY_ID

2 Description 600 <null>

Table A–2 E_ENTRY, Case Login, STUDY_ID_M0


1 Study 200 AE_CASES.STUDY_ID



Record group for centers: OCL_SITESThis section describes the definition and field LOV mappings for record group OCL_SITES.


Field LOV mappingsThe following tables contain the field LOV mappings for the OCL_SITES record group. Each table title lists the form, window, and item.


Table A–3 Q_QUERY, Demographics, STUDY_ID_M0


1 Study 200 AE_CASES.STUDY_ID_M0


Table A–4 Q_QUERY, Case Login, STUDY_ID_M1




Table A–5 Q_QUERY, Quick Query, STUDY_ID_M2




Codelist LOV name Codelist executable text

OCL_SITES COMMON_3_COLUMN_LOV SELECT B.STUDY_SITE COL1,

C.CITY COL2,

C.COUNTRY COL3

FROM CLINICAL_STUDY_VERSIONS@ORACLIN A,

OCL_STUDY_SITES@ORACLIN B,

OCL_SITES@ORACLIN C

WHERE A.LIVE_STUDY_FLAG = 'Y'

AND A.STUDY = = :AE_CASES.STUDY_ID

AND A.CLINICAL_STUDY_ID = B.CLINICAL_STUDY_ID

AND B.SITE_ID = C.SITE_ID

Table A–2 (Cont.) E_ENTRY, Case Login, STUDY_ID_M0




Record group for Investigators: OCL_INVESTIGATORSThis section describes the definition and field LOV mappings for record group OCL_INVESTIGATORS.

Table A–6 E_ENTRY, Demographics, CENTER_ID


1 Center 200 AE_CASES.CENTER_ID

2 City 300 <null>

3 Country 100 <null>

Table A–7 E_ENTRY, Case Login, CENTER _ID_M0


1 Center 200 AE_CASES.CENTER_ID_M0

2 City 300 <null>


Table A–8 Q_QUERY, Demographics, CENTER_ID



2 City 300 <null>


Table A–9 Q_QUERY, Case Login, CENTER _ID_M2


1 Center 200 AE_CASES.CENTER_ID_M

2 City 300 <null>


Table A–10 Q_QUERY, Quick Query, CENTER _ID_M1



2 City 300 <null>





Field LOV MappingsThe following tables contain the field LOV mappings for the OCL_INVESTIGATORS record group. Each table title lists the form, window, and item.

Codelist LOV Name Codelist Executable Text

OCL_INVESTIGATORS

COMMON_5_COLUMN_LOV SELECT C.INVESTIGATOR COL1,

C.LAST_NAME COL2,

C.FIRST_NAME COL3,

C.CITY COL4,

C.COUNTRY COL5

FROM CLINICAL_STUDY_VERSIONS@ORACLIN A,

OCL_STUDY_SITE_ROLES@ORACLIN B,

OCL_INVESTIGATORS@ORACLIN C

WHERE A.LIVE_STUDY_FLAG = 'Y'

AND A.STUDY = :AE_CASES.STUDY_ID


AND B.INVESTIGATOR_ID = C.INVESTIGATOR_ID

Table A–11 E_ENTRY, Demographics, INVEST_ID


1 Investigator 200 AE_CASES. INVEST _ID

2 Last Name 200 <null>

3 First name 200 <null>

4 City 300 <null>


Table A–12 E_ENTRY, Case Login, INVEST_ID_M0


1 Investigator 200 AE_CASES. INVEST _ID



4 City 300 <null>


Table A–13 Q_QUERY, Demographics, INVEST_ID


1 Investigator 200 AE_CASES. INVEST _ID_M0




Record group for patient details: OCL_PATIENTS (multicolumn)You should only apply this record group to the fields in data entry. Create a second, standard record group for query fields.

This section describes the definition and field LOV mappings for record group OCL_PATIENTS.


4 City 300 <null>


Table A–14 Q_QUERY, Case Login, INVEST_ID_M2





4 City 300 <null>


Table A–15 Q_QUERY, Quick Query, INVEST_ID_M1





4 City 300 <null>


Table A–13 (Cont.) Q_QUERY, Demographics, INVEST_ID





Field LOV MappingsThe following tables contain the field LOV mappings for the OCL_PATIENTS record group. Each table title lists the form, window, and item.

Codelist LOV Name Codelist Executable Text

OCL_PT_ DETAILS

COMMON_4_COLUMN_LOV SELECT A.PATIENT COL1,

A.REPORTED_INITIALS COL2,

TO_CHAR (A.REPORTED_BIRTH_DATE,

' DD-MON-YYYY') COL3,

A.REPORTED_SEX COL4

FROM PATIENT_POSITIONS@ORACLIN A,

CLINICAL_STUDY_VERSIONS@ORACLIN B,

STUDY_SITE_PATIENT_POSITIONS@ORACLIN C,

STUDY_SITES@ORACLIN D

WHERE B.STUDY = :AE_CASES.STUDY_ID

AND B.LIVE_STUDY_FLAG = 'Y'

AND D.STUDY_SITE = :AE_CASES.CENTER_ID

AND C.SITE_ID = D.SITE_ID


AND A.CLINICAL_STUDY_VERSION_ID =

B.CLINICAL_STUDY_VERSION_ID

AND A.CLINICAL_STUDY_ID = C.CLINICAL_STUDY_ID

AND A.PATIENT_POSITION_ID = C.PATIENT_POSITION_ID

Table A–16 E_ENTRY, Demographics, PATIENT_ID


1 Patient 200 AE_CASES.PATIENT_ID

2 Patient Initials 100 AE_CASES.PT_INITLS

3 Birth Date 100 AE_CASES.PT_DOB

4 Sex 50 AE_CASES.PT_SEX

Table A–17 E_ENTRY, Case Login, CENTER _ID_M0


1 Patient 200 AE_CASES.PATIENT_ID_M0

2 Patient Initials 100 AE_CASES.PT_INITLS_M0

3 Birth Date 100 AE_CASES.PT_DOB_M0

4 Sex 50 AE_CASES.PT_SEX_M0

Oracle Clinical reconciliation views


Oracle Clinical reconciliation viewsOracle AERS reconciliation is performed against a staging area that holds the clinical data. When you use Oracle AERS with applications other than Oracle Clinical, you load these tables from a batch process based on an ASCII extract file. For Oracle Clinical however, you can implement custom extract views against the Oracle Clinical database. These views are suffixed with "_OC" on the staging table name. They are then automatically unioned into the main Reconciliation views. The success of the extract view method depends on two factors:

■ the degree of standardization in the naming of the fields involved in reconciliation

■ the completeness of the Oracle Clinical implementation

If your company does not standardize the question names for key reconciliation fields, it is more difficult to build and maintain the cross-study data extract views.

Table A–18 Q_QUERY, Demographics, CENTER_ID



2 City 300 <null>


Table A–19 Q_QUERY, Case Login, CENTER _ID_M2


1 Center 200 AE_CASES.CENTER_ID_M

2 City 300 <null>


Table A–20 Q_QUERY, Quick Query, CENTER _ID_M1



2 City 300 <null>


Oracle Clinical reconciliation views


Date post:	18-Nov-2014
Category:	Documents
Upload:	api-26966400
View:	421 times
Download:	1 times