9i And 10g Difference
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View 9i And 10g Difference as PDF for free.
More details
- Words: 76,648
- Pages: 250
Oracle® Adverse Event Reporting System Administrator’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..................................................................................................................................... xiii Documentation Accessibility ................................................................................................................... xiv New in Oracle AERS 4.5.2 ....................................................................................................................... xiv Structure ..................................................................................................................................................... xv Related Documents .................................................................................................................................. xvii Conventions ............................................................................................................................................. xviii Checking MetaLink ................................................................................................................................. xviii
1
Oracle AERS overview Lock Manager............................................................................................................................................ Oracle AERS interface ............................................................................................................................. Navigator panel.................................................................................................................................. Console ................................................................................................................................................ Message line........................................................................................................................................ Status line ............................................................................................................................................ Toolbars .............................................................................................................................................. Oracle AERS features .............................................................................................................................. Basic querying (search) techniques ................................................................................................. Querying with wild cards ................................................................................................................. Function keys ...................................................................................................................................... Shortcut keys (key commands) ........................................................................................................ Closing/exiting before saving your work ......................................................................................
2
1-1 1-1 1-1 1-1 1-1 1-2 1-2 1-2 1-2 1-2 1-3 1-4 1-4
Administration overview Company product repository ................................................................................................................. Users and user group permissions........................................................................................................ Workflow tasks/data entry...................................................................................................................... Data management..................................................................................................................................... Reports........................................................................................................................................................ Query .......................................................................................................................................................... Dictionaries ............................................................................................................................................... Controls ......................................................................................................................................................
2-1 2-1 2-2 2-2 2-3 2-3 2-3 2-3
iii
3
Controls Discussion of the Controls table ........................................................................................................... 3-1 Listing and descriptions of AERS Controls ........................................................................................ 3-1
4
AERS Portal Portal components.................................................................................................................................... Implementing AERS Portal .................................................................................................................... AERS Portal Users and User Groups .............................................................................................. Modifying the AERS Home Page .................................................................................................... Modifying the Home Page attributes....................................................................................... Modifying the Pharma Solutions section ................................................................................ The Administration section ....................................................................................................... Modifying AERS Folders ........................................................................................................... AERS Documents custom items ............................................................................................... AERS Reports .............................................................................................................................. Modifying the AERS Portal Applications....................................................................................... AERS External Applications/Single Sign-on ...................................................................................... AERS 4.5.2 ........................................................................................................................................... AERS 4.5.2 Global Maintenance....................................................................................................... AERS 4.5.2 Workflow Configuration ..............................................................................................
4-2 4-3 4-3 4-3 4-3 4-4 4-4 4-4 4-5 4-6 4-6 4-6 4-6 4-7 4-7
5 Managing company product information Product Codes ........................................................................................................................................... 5-1 Adding Product Codes...................................................................................................................... 5-1 Updating Product Codes................................................................................................................... 5-2 Deleting Product Codes .................................................................................................................... 5-3 Company Products ................................................................................................................................... 5-3 Product details .................................................................................................................................... 5-3 Adding a Company Product ..................................................................................................... 5-3 Updating Company Products ................................................................................................... 5-4 Deleting Company Products ..................................................................................................... 5-5 Approvals ............................................................................................................................................ 5-5 Adding an approval ................................................................................................................... 5-5 Updating an approval ................................................................................................................ 5-6 Deleting approvals...................................................................................................................... 5-6 Labeling ............................................................................................................................................... 5-7 Adding Drug Labeling ............................................................................................................... 5-7 Deleting drug labeling associated with company drugs ...................................................... 5-7 Lots ....................................................................................................................................................... 5-8 Adding Lot details ...................................................................................................................... 5-8 Updating Lot details ................................................................................................................... 5-9 Deleting Lot details.................................................................................................................. 5-10 Exposure ........................................................................................................................................... 5-10 Updating Exposure details ..................................................................................................... 5-10 Updating Exposure details ..................................................................................................... 5-11 Deleting Exposure details ....................................................................................................... 5-11
iv
Contacts ............................................................................................................................................ Updating contacts .................................................................................................................... Deleting a contact..................................................................................................................... Packaging ......................................................................................................................................... Adding packaging details....................................................................................................... Deleting packaging details ..................................................................................................... Product Labels........................................................................................................................................ Creating a New Label ..................................................................................................................... Creating a New Version of a Label............................................................................................... Viewing Label Versions .......................................................................................................... Adding Event Terms ............................................................................................................... Label Qualifications ................................................................................................................. Activating a Label ........................................................................................................................... Copying an Existing Label.............................................................................................................
6
Maintaining the AERS-TMS Dictionary Conceptual Overview .............................................................................................................................. AERS-TMS MedDRA Implementation ........................................................................................... AERS-TMS WHO Drug Implementation ....................................................................................... Adding Company Products .................................................................................................................... Adding products to the AERS-TMS dictionary ............................................................................ Activating your newly added dictionary terms ............................................................................ Using TMS Domains ............................................................................................................................... Creating and using TMS Search Objects............................................................................................. Running Batch Reclassify.......................................................................................................................
7
5-12 5-12 5-12 5-13 5-13 5-13 5-14 5-14 5-15 5-15 5-15 5-15 5-16 5-17
6-1 6-1 6-1 6-2 6-3 6-7 6-7 6-8 6-8
Studies Maintaining Study Attributes ............................................................................................................... Study Security..................................................................................................................................... Study Products ................................................................................................................................... Adding Studies ......................................................................................................................................... Updating Studies...................................................................................................................................... Deleting Studies .......................................................................................................................................
7-1 7-2 7-2 7-2 7-2 7-2
8 Product Groups Defining Product Groups ....................................................................................................................... Adding Product Groups.......................................................................................................................... Updating Product Groups....................................................................................................................... Deleting Product Groups........................................................................................................................
9
8-1 8-1 8-2 8-2
Configuring AERS for multilingual use Overview of multilingual architecture ................................................................................................ Maintaining AERS Local Languages.................................................................................................... Setting a User’s Local Language............................................................................................................ Maintaining Codelist Translations .......................................................................................................
9-1 9-1 9-2 9-2
v
Maintaining Field and Window Label Translations ......................................................................... Adding Field Label Translations ..................................................................................................... Adding Window Label Translations ............................................................................................... Maintaining Error Messages and Translations................................................................................... Adding Error Message Translations ...............................................................................................
10
Supporting your work processes Case statuses........................................................................................................................................... Action items............................................................................................................................................ Document templates ............................................................................................................................. Creating the template PL/SQL .................................................................................................... Loading the template...................................................................................................................... Defining the template in the LETTERS table .............................................................................. Workflow tasks ...................................................................................................................................... Defining Workflow tasks ............................................................................................................... Assigning Workflow tasks to users .............................................................................................. Designing screens ................................................................................................................................. Global screens and fields configuration....................................................................................... FIELD_ATTRIBUTES Table Description .............................................................................. WDW_ATTRIBUTES Table Description ............................................................................ Modifying the global screens and fields configuration attributes ......................................... Revealing custom fields ............................................................................................................... Workflow-specific screens and fields configuration................................................................ FIELD_MODES Table............................................................................................................ WINDOW_MODES Table .................................................................................................... Modifying Workflow-specific screen and field configuration ............................................... Configuring the data entry Navigator panel.................................................................................. Creating the Code List entry ....................................................................................................... Creating Record Groups .............................................................................................................. Creating the SQL statement to display the Navigator view ................................................... Configuration consistency constraints............................................................................................
11
10-1 10-3 10-3 10-3 10-4 10-4 10-5 10-6 10-8 10-8 10-9 10-9 10-11 10-12 10-12 10-13 10-13 10-13 10-14 10-14 10-15 10-15 10-16 10-17
Managing Users And User Groups Overview of Oracle AERS user security ........................................................................................... Security objects ................................................................................................................................ User groups............................................................................................................................... Users .......................................................................................................................................... Types of Oracle AERS security ..................................................................................................... Case ownership ........................................................................................................................ Case permissions...................................................................................................................... Oracle Roles .............................................................................................................................. Portal Roles/Groups ............................................................................................................... Oracle AERS User Roles.......................................................................................................... Setting up Oracle AERS for users ...................................................................................................... Managing Oracle AERS Roles ............................................................................................................ Maintaining user groups...................................................................................................................... Understanding user group permissions ......................................................................................
vi
9-3 9-3 9-4 9-4 9-4
11-1 11-1 11-1 11-2 11-2 11-2 11-2 11-3 11-3 11-3 11-3 11-3 11-4 11-5
Adding permissions to a user group............................................................................................ Adding user groups........................................................................................................................ Updating user groups..................................................................................................................... Deleting user groups ...................................................................................................................... Maintaining users ................................................................................................................................. Creating AERS users....................................................................................................................... Assigning Oracle passwords ......................................................................................................... Assigning roles ................................................................................................................................ Baseline Oracle Roles............................................................................................................... Optional AERS Roles............................................................................................................... Other AERS Application Roles ............................................................................................ Portal Groups (Roles) ............................................................................................................ Assigning roles to a user ....................................................................................................... Updating user attributes and permissions ................................................................................ User permissions.................................................................................................................... Local privacy and security ................................................................................................................. Configuration Components ......................................................................................................... Example 1: Local Privacy configuration for patient name and address ............................... Example 2: Local Security configuration for assessment data ............................................... Configuration Procedure ............................................................................................................. Record-level filtering.......................................................................................................................... Configuration components .......................................................................................................... Example 1: Reportability/Submission History filtering for local affiliate............................ Example 2: Investigation filtering for Product Complaint investigation users ................... Configuration Procedure ............................................................................................................. Managing passwords.......................................................................................................................... Configuring passwords................................................................................................................ Unlocking Single Sign-On (SSO)................................................................................................. Configuring application-level timeout ...................................................................................... Resetting a user’s password ........................................................................................................ Changing the PORTAL30 Password ..........................................................................................
11-5 11-5 11-6 11-6 11-7 11-7 11-8 11-8 11-8 11-9 11-10 11-11 11-11 11-12 11-13 11-14 11-14 11-15 11-15 11-16 11-16 11-17 11-17 11-18 11-18 11-21 11-21 11-21 11-22 11-22 11-23
12 Data management Change reason codes............................................................................................................................. TE_CASE_VERSION/TH_CASE_VERSION view .................................................................... Duplicate checking ............................................................................................................................... Duplicate check API........................................................................................................................ Description................................................................................................................................ Input parameters...................................................................................................................... Output ....................................................................................................................................... Duplicate Check logic..................................................................................................................... Clinical AE Cases ..................................................................................................................... Non-Clinical AE Cases (Spontaneous, Registry, Literature, etc.) ..................................... Product Complaint Cases ....................................................................................................... Copy Case ............................................................................................................................................... Generic implementation................................................................................................................. Data derivation procedures .................................................................................................................
12-1 12-1 12-2 12-2 12-2 12-2 12-3 12-3 12-4 12-4 12-5 12-5 12-5 12-8
vii
Case ID generation.......................................................................................................................... Updating the Case ID generation algorithm........................................................................ Case data derivations ..................................................................................................................... Field/Record/Record block, DB derivations ...................................................................... Updating and compiling the derivation library .................................................................. Generating the library ........................................................................................................... Standard derivation procedures .......................................................................................... Field code lists...................................................................................................................................... Adding new code lists .................................................................................................................. Step 1: Create the new code list ........................................................................................... Step 2: Add individual code list items ................................................................................ Step 3: Create a Record Group ............................................................................................. Step 4: Assigning code lists to fields ................................................................................... Creating SQL lookup code lists................................................................................................... Updating existing code lists ........................................................................................................ Updating an item in a code list ............................................................................................ Retiring code list values ........................................................................................................ Reactivating retired individual code list items.................................................................. Deleting code lists ......................................................................................................................... Deleting individual code list items............................................................................................. Edit checks ............................................................................................................................................ Updating the edit check program............................................................................................... Table descriptions ......................................................................................................................... RULE_ATTRIBUTES table.................................................................................................... RULE_FIRING_MODES table..............................................................................................
12-8 12-9 12-9 12-9 12-9 12-10 12-11 12-13 12-14 12-14 12-14 12-15 12-15 12-16 12-17 12-17 12-18 12-18 12-18 12-19 12-19 12-20 12-20 12-21 12-21
Edit check example 22 Spell Check........................................................................................................................................... Configuring for Microsoft Word................................................................................................. Installing JSpell in Oracle AERS ................................................................................................. Reconciliation ...................................................................................................................................... Modifying Reconciliation............................................................................................................. Staging tables ................................................................................................................................. RCN_CASES table ................................................................................................................. RCN_PATIENT table ............................................................................................................ RCN_PATIENT_VITALS table ............................................................................................ RCN_PT_AE_PROFILE table ............................................................................................... RCN_PT_CAUSE_DEATH table ......................................................................................... RCN_PT_DOSING table ....................................................................................................... Clinical data extract file ..................................................................................................................... Coded field translations ............................................................................................................... Clinical extract load program......................................................................................................
12-22 12-23 12-23 12-24 12-24 12-26 12-26 12-27 12-27 12-28 12-29 12-29 12-30 12-31 12-31
13 Configuring Case Browse Overview................................................................................................................................................. Modes................................................................................................................................................ Field Attributes................................................................................................................................ Relevant Field Modes .....................................................................................................................
viii
13-1 13-1 13-1 13-2
Adding or Updating a Custom Browse Configuration .................................................................. 13-3 Fields Available for Configuration .................................................................................................... 13-4 Out-of-the-Box Case Browse Configuration .................................................................................... 13-6
14
Case Data Query Query configuration ............................................................................................................................. Modifying existing query configuration...................................................................................... Adding new query fields ............................................................................................................... Creating support views........................................................................................................... Adding the Query Table Join ................................................................................................. Adding a new field to the query screens.............................................................................. Adding an Exclude Flag to a new block ............................................................................... Adding custom queries ........................................................................................................................
15
E2B Configuration Run-Time Parameters ........................................................................................................................... Export processing .................................................................................................................................. Configuring E2B Export (submissions)........................................................................................ E2B_RECEVIERS Table .................................................................................................................. Import processing.................................................................................................................................. Import Rules .................................................................................................................................... E2B Data Mapping .............................................................................................................................. E2B Automation Features .................................................................................................................. Supported Automation Features ................................................................................................ Gateway Event and MDN Processing........................................................................................ Batch_Import ................................................................................................................................. Error handling ............................................................................................................................... Configuring Automation .............................................................................................................
16
15-1 15-2 15-2 15-2 15-6 15-7 15-11 15-13 15-13 15-14 15-15 15-16 15-17
Creating and managing document templates Document templates ............................................................................................................................. Creating the template PL/SQL .................................................................................................... Loading the template...................................................................................................................... Defining the template in the LETTERS table ..............................................................................
17
14-1 14-1 14-4 14-4 14-5 14-5 14-6 14-6
16-1 16-1 16-2 16-2
Managing programs and reports Installing new reports .......................................................................................................................... Registering new reports on the Oracle Report Security Server................................................ Installing new reports on Oracle AERS ....................................................................................... Defining report parameters................................................................................................................. Deleting reports ..................................................................................................................................... Removing reports From the Portal Reports Security Registry ................................................. Deleting reports on Oracle AERS ................................................................................................. Configuring Oracle AERS reports ..................................................................................................... Configuring code lists used by reports .............................................................................................
17-1 17-1 17-2 17-3 17-4 17-4 17-4 17-4 17-5
ix
Managing report decode values.................................................................................................... 17-5 Configuring default values for program parameters ..................................................................... 17-6 Configuring report parameter cross-validation............................................................................... 17-6
Client extensions example 8 Customizable views used by reports................................................................................................. 17-8 Configuring ad hoc reporting tools .............................................................................................. 17-9 Adding the company logo for MedWatch report ............................................................................ 17-9
18
Submission management Overview of Submission Tracking functions and supporting configuration ........................... Running the Submission Wizard .................................................................................................. Maintaining Reportability Rules ....................................................................................................... Reportability Rule Syntax .............................................................................................................. Setting the case data level of reportability criteria ..................................................................... Creating or modifying a Reportability Rule Template.............................................................. Applying a Reportability Rule Template..................................................................................... Managing individual reportability for an Approval ................................................................. Maintaining Agency Reports .............................................................................................................. Adding Agencies/Reports............................................................................................................. Updating and deleting Agencies and Reports............................................................................ AGENCY_REPORTS table definition ..........................................................................................
18-1 18-2 18-3 18-3 18-4 18-5 18-5 18-6 18-6 18-7 18-7 18-7
19 Oracle AERS dictionary architecture Overview of AERS Dictionary Functionality .................................................................................. Dictionary Columns........................................................................................................................ AERS, Dictionary Management, and TMS .................................................................................. AERS Dictionary Related Functions............................................................................................. AERS Dictionary API Definition ....................................................................................................... Dictionary Interface Data Model .................................................................................................. Definitions................................................................................................................................. Dictionary Version Support and Domains .................................................................................. SetDomain Function ................................................................................................................ GetCurrentDomainFunction Function.................................................................................. V_DICT_DOMAINS ................................................................................................................ Classification.................................................................................................................................... Batch Reclassify ........................................................................................................................ Reporting and High Level Term Derivation ............................................................................... V_ACTIVE_SUBSTANCES .................................................................................................... V_SPEC_CAT ........................................................................................................................... AERS Dictionary Query ................................................................................................................. Dictionary Pipeline Function ................................................................................................. Dictionary Search Dialog Box .............................................................................................. Derived Unexpectedness ............................................................................................................. Dictionary Content Views............................................................................................................ V_MEDDRA_TERMS ............................................................................................................ V_PRODUCT_NAMES ........................................................................................................ V_REGULATORY_GROUP_NAMES................................................................................. x
19-1 19-1 19-2 19-2 19-2 19-3 19-3 19-3 19-3 19-4 19-4 19-4 19-6 19-7 19-8 19-8 19-8 19-9 19-10 19-10 19-11 19-11 19-11 19-12
AERS TMS Interface Module .......................................................................................................... AERS Standard Dictionaries in TMS .......................................................................................... AERS enhancements to WHO Drug ................................................................................... AERS Enhancements to MedDRA....................................................................................... Reporting view modes ................................................................................................................. Classic Mode........................................................................................................................... Clinical Compatibility Mode................................................................................................ AERS/TMS Concept Mapping.................................................................................................... Interface Module Tables............................................................................................................... AERS_TMS_DICTIONARY_COLUMNS Table ................................................................ AERS_TMS_TERM_ROWS................................................................................................... AERS Controls Table Entries................................................................................................ Notes on AERS_Dictionary_API Package ................................................................................. GetCurrentDomainFunction ................................................................................................ GetLastOmissionKey............................................................................................................. ReclassifyCase ........................................................................................................................ Search....................................................................................................................................... V View Implementation ............................................................................................................... Forms Implementation ................................................................................................................. Drill Down Views.......................................................................................................................... TMS integration Install................................................................................................................. TMS Configuration and Dictionary Loading..................................................................... AERS Standard TMS API Install.......................................................................................... Derived Unexpectedness and Product Labels .......................................................................... Metadata and Label Versions............................................................................................... Label Maintenance Form ......................................................................................................
20
19-12 19-13 19-13 19-15 19-15 19-15 19-15 19-15 19-16 19-16 19-17 19-17 19-18 19-18 19-18 19-18 19-18 19-19 19-19 19-19 19-19 19-20 19-20 19-20 19-20 19-21
Architectural details Audit trail................................................................................................................................................ 20-1 Data model naming conventions ....................................................................................................... 20-1
A
Oracle Clinical configuration Setting up value lookups from Oracle Clinical................................................................................. Step 1: Define record group ............................................................................................................. Step 2: Assign record groups to fields............................................................................................ Step 3: Define the LOV columns ..................................................................................................... Specific Oracle lookups ......................................................................................................................... Record group for clinical studies: OCL_STUDIES ....................................................................... Record group definition............................................................................................................ Field LOV Mappings ................................................................................................................. Record group for centers: OCL_SITES........................................................................................... Record group definition............................................................................................................ Field LOV mappings ................................................................................................................. Record group for Investigators: OCL_INVESTIGATORS .......................................................... Record group definition............................................................................................................ Field LOV Mappings .................................................................................................................
A-1 A-1 A-2 A-2 A-3 A-3 A-3 A-3 A-4 A-4 A-4 A-5 A-6 A-6
xi
Record group for patient details: OCL_PATIENTS (multicolumn) .......................................... Record group definition............................................................................................................ Field LOV Mappings ................................................................................................................. Oracle Clinical reconciliation views....................................................................................................
xii
A-7 A-8 A-8 A-9
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 audience The 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 administrators Installing 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 administrators Maintaining 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 xiii
■
setting and using environment variables
Documentation Accessibility Our 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 Documentation Screen 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 Documentation This 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 Services Oracle 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 Unexpectedness AERS 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 Dates Some 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.
xiv
Enhance the AERS Product Label Repository The 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 10g The AERS technology stack is upgraded to 10G from Forms 6 and Reports 9iDS.
Structure This 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.
xv
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.
xvi
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 Documents This 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 Documentation The 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) Documentation The 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) Documentation The 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)
xvii
Oracle Clinical SiteMinder Documentation The Oracle Clinical SiteMinder documentation includes: ■
Oracle Clinical SiteMinder User Guide (B15643)
■
Oracle Clinical SiteMinder Installation Guide (B15645)
Oracle Clinical TrialMinder Documentation The 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)
Conventions The following text conventions are used in this document: 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.
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:
xviii
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.
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.
xix
xx
1 Oracle 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 Manager The 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 interface This 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 panel The 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.
Console The 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 line Two types of messages may be displayed on this line: ■
Oracle® Forms™ standard messages.
■
Application-specific messages Oracle AERS overview 1-1
Oracle AERS features
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 line The Status Line displays helpful information about particular fields or records in a block. 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
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 features This 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) techniques The 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 cards When 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 1-2 Oracle Adverse Event Reporting System Administrator’s Guide
Oracle AERS features
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: Operator
Description
Example
%
Wild card (one or more characters)
A%
_
Wild card (single character only)
A_pirin
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 keys Function 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. 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)
Oracle AERS overview 1-3
Oracle AERS features
Table 1–2 (Cont.) Function keys Key
Action
Ctrl + Z
Undo last editing
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 work If 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.
1-4 Oracle Adverse Event Reporting System Administrator’s Guide
2 Administration 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 repository The 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 permissions Users 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
Administration overview
2-1
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 entry A 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 management Oracle 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.
2-2 Oracle Adverse Event Reporting System Administrator’s Guide
Controls
Reports Oracle 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.
Query The 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.
Dictionaries Oracle 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".
Controls The Controls tables are present at each site. The tables contain a number of specific, site-wide parameters that control various features of the application.
Administration overview
2-3
Controls
2-4 Oracle Adverse Event Reporting System Administrator’s Guide
3 Controls 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 table The 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 Controls The 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.ht ml
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 Discoverer Viewer on hoc data visualization environment. 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.
Controls
3-1
Listing and descriptions of AERS Controls
Table 3–1 (Cont.) AERS Controls Table CONTROL_ID
CONTROL_VALUE
Default Value
AERS_LETTER_URL
The URL used to launch the letter generation page. This item is not configurable.
Portal To AERS. Show Letter? p_ lettername=LETTER NAME
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
YYYYS1 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).
CASE_CLOSED_ STATUS
Case Status for a closed case.
CLOSE_REASON_LIST
C 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
N 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.
ERROR_LOGGER_JOB
The job ID for the AERS Error Logger.
3-2 Oracle Adverse Event Reporting System Administrator’s Guide
(Set at installation)
Listing and descriptions of AERS Controls
Table 3–1 (Cont.) AERS Controls Table CONTROL_ID
CONTROL_VALUE
Default Value
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/b rowser/tms_user_ browser_ finddemo.openfram e?pdictid=72
FORCE_UPR_IN_QK_ OPEN
Values: Y/N. When set to ‘Y,’ the Case Y ID entered in the Quick Open dialog box is automatically converted to upper case.
GMT_TIME_OFFSET
Difference in time (±)(HH:MM) between 0:00 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).
HELP_URL_PREFIX
The location of the xHelp system.
http://forms_ server/opa45/xhel p
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 PATIENT_CONTEXT_ Extract Load. 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.selectite mtype…
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
Controls
3-3
Listing and descriptions of AERS Controls
Table 3–1 (Cont.) AERS Controls Table CONTROL_ID
CONTROL_VALUE
Default Value
PORTAL_PLS_URL
The URL for the Portal DAD.
http://forms server/pls/portal 30
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
DELETE 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.
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
e.g. jspell_ This specifies the HTTP server and port server.oracle.com:80 where JSpell servlet is installed,. If left blank, it implies the JSpell servlet is installed in the same server as the Forms server.
SUB_EXCLD_STATUS_ Setting specifying the case status of cases 0 1 to be excluded from submission reports; e.g., exclude all cases with status of 1 (Login). SUBWIZ_USE_ EVENT_TO_DRUG_ ASSESSMENT
When Y, the Submission Wizard uses the Y lowest level information available for determining reportability. When N, the case level flags are used.
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 TERM_REASON_LIST Extract Load.
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.
3-4 Oracle Adverse Event Reporting System Administrator’s Guide
151
Listing and descriptions of AERS Controls
Table 3–1 (Cont.) AERS Controls Table CONTROL_ID
CONTROL_VALUE
Default Value
TMS_XSYSTEM_KEY
The external system integration key used AERS1 by this instance of AERS to access TMS. Our standard is to use the AERS schema name.
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.
WARNING_TIMEOUT
The inactivity time in seconds, before the 1200 timeout warning screen displays.
US_REP_TYPE_LIST
Controls
3-5
Listing and descriptions of AERS Controls
3-6 Oracle Adverse Event Reporting System Administrator’s Guide
4 AERS 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 overview Oracle Portal has a three-tier architecture that scales to suit any sized company. The tier components are:
AERS Portal 4-1
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 components AERS 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 page A 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.
Portlet A 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 areas Content 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.
4-2 Oracle Adverse Event Reporting System Administrator’s Guide
Implementing AERS Portal
Applications An 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 Applications Oracle 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 Portal Oracle 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 Groups Each 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 Page The 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 attributes The 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).
AERS Portal 4-3
Implementing AERS Portal
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 section Pharma 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 section The 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 Folders The 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.
4-4 Oracle Adverse Event Reporting System Administrator’s Guide
Implementing AERS Portal
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 items Within 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 Portal 4-5
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 Reports The 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 Applications Oracle 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-on Oracle 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.2 The AERS 4.5.2 external application corresponds to the main AERS system (case management, query, reporting, etc.).
4-6 Oracle Adverse Event Reporting System Administrator’s Guide
AERS External Applications/Single Sign-on
AERS 4.5.2 Global Maintenance The 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 Configuration The 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.
AERS Portal 4-7
AERS External Applications/Single Sign-on
4-8 Oracle Adverse Event Reporting System Administrator’s Guide
5 Managing 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 Codes A 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). You can maintain Product Codes by using the Oracle AERS Global Maintenance subsystem.
Note:
Adding Product Codes A 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.
Managing company product information 5-1
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: ■
■ ■
■
5.
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).
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 Codes You 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. The Products Maintenance 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.
Key in changes to the Description field.
4.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the updated Description to the database.
5-2 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
Deleting Product Codes 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.
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.
4.
Click the Save button or press the F10 key to save changes. You do not receive a prompt. Oracle AERS deletes the Product Code from the database.
Company Products Oracle 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 details The 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. The Oracle AERS dictionary structure and interface are fully described in Chapter 19, "Oracle AERS dictionary architecture" of this guide. Note:
Adding a Company Product In 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 Managing company product information 5-3
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. We recommend creating the Product Code first. See Adding Product Codeson on page 5-1.
Note:
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.
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. ■
■
■
■
■
4.
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.
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 Products To update a product: 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.
Select a Product from the Navigator panel.
3.
Key in the appropriate changes.
4.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the changes.
5-4 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
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).
Deleting Company Products To delete a product: 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.
Select a Product from the Navigator panel.
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.
4.
Click the Save button, press the F10 key, or select File=>Save to save changes.
Approvals Oracle 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 approval To add a product approval: 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. Managing company product information 5-5
Company Products
2.
Select a Product from the Navigator panel.
3.
Select the Approvals tab. The Approval tab displays.
4.
Key in all fields. ■
Country: The Country or Agency providing the license/approval.
■
Type: The license type
■
License Number
■
License Date
■
■
■
■
■
5.
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.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the Approval to the database.
Updating an approval To update an approval: 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.
Select a Product from the Navigator panel.
3.
Select the Approvals tab. The Approval tab displays.
4.
Key in the appropriate changes.
5.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the changes to the database.
Deleting approvals To delete a Approval: 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.
Select a Product from the Navigator panel.
3.
Select the Approvals tab. The Approval tab displays.
5-6 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
4.
Highlight the Approval record to be removed 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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the Approval to the database.
Labeling Core 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 Labeling To add Drug Labeling: 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.
Select a Product from the Navigator panel.
3.
Select the Labeling tab. The Labeling tab displays.
4.
Key in all fields. ■
■
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.
■
■
5.
Core Label Name - Use the codelist to associate the core label with a product label.
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.
Press the Save button or F10 to save changes. Oracle AERS saves the Approval to the database.
Deleting drug labeling associated with company drugs To delete a Labeling: 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.
2.
Select a Product from the Navigator panel.
3.
Select the Labeling tab. The Labeling tab displays.
Managing company product information 5-7
Company Products
4.
Highlight the Labeling record to be removed 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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS deletes the Labeling from the database.
Lots Oracle 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 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.
Note:
To load Lot details directly into tables: 1.
Prepare a text file that matches the following load specifications:
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.
5-8 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
Column
Req? Type
Start
Stop
Description
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.
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. The Labeling tab displays.
4.
Run the LOAD_LOTS.CTL SQL*Loader file connected as the schema owner of Global Maintenance tables.
To add Lot details manually: 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.
Select a Product from the Navigator panel.
3.
Select the Lot tab. The Lot tab displays.
4.
5.
Key in all fields. ■
Label Lot
■
Fill Lot
■
Bulk Lot
■
Package Lot
■
Expiration Date
■
Distribution Date
■
Number of Doses
■
NDC
■
Manufacturer
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the Lot information to the database.
Updating Lot details To update Lot details: 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.
Managing company product information 5-9
Company Products
2.
Select a Product from the Navigator panel.
3.
Select the Lot tab. The Lot tab displays.
4.
Key in the appropriate changes.
5.
Press the Save button or F10 to save changes. Oracle AERS saves the changes to the database.
Deleting Lot details To delete Lot details: 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.
Select a Product from the Navigator panel.
3.
Select the Lot tab. The Lot tab displays.
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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Exposure Oracle 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 details You 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)
The Product Formulation. This field must match the Drug Form
Y
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
5-10 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
Column
Data Type
Req?
Description
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.
To add Exposure details manually: 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.
Select a Product from the Navigator panel.
3.
Select the Exposure tab. The Exposure tab displays.
4.
5.
Key in all fields. ■
Exposure Month
■
Exposure Measure
■
Indication
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the Lot information to the database.
Updating Exposure details To update Exposure details: 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.
Select a Product from the Navigator panel.
3.
Select the Exposure tab. The Exposure tab displays.
4.
Key in the appropriate changes.
5.
Press the Save button or F10 to save changes. Oracle AERS saves the changes to the database.
Deleting Exposure details To delete Exposure details: 1.
Select the Products tab from the Oracle AERS Global Maintenance subsystem.
Managing company product information 5-11
Company Products
The Products Maintenance screen displays with the list of Company Products visible in the Navigator panel. 2.
Select a Product from the Navigator panel.
3.
Select the Exposure tab. The Exposure tab displays.
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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Contacts A 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: 1.
Select a Product from the Navigator panel.
2.
Select the Contact tab. The Contact tab displays.
3.
Key in all fields.
4.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the Contact to the database.
Updating contacts To update contact information: 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.
Select a Product from the Navigator panel.
3.
Select the Contact tab. The Contact tab displays.
4.
Key in the appropriate changes.
5.
Press the Save button or F10 or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Deleting a contact To delete a Contact: 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.
5-12 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
2.
Select a Product from the Navigator panel.
3.
Select the Contact tab. The Contact tab displays.
4.
Highlight the Contact record to be removed 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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Packaging Oracle 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. 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.
Adding packaging details To add Packaging details: 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.
Select a Product from the Navigator panel.
3.
Select the Packaging tab. The Packaging tab displays.
4.
Enter the packaging details.
5.
Click the Save button. Oracle AERS saves the changes to the database.
Deleting packaging details To delete packaging details: 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.
Managing company product information 5-13
Product Labels
2.
Select a Product from the Navigator panel.
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. You do not receive a prompt. The Product Code is deleted from the database.
5.
Click the Save button or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Product Labels The 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 Label New 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.
5-14 Oracle Adverse Event Reporting System Administrator’s Guide
Product Labels
Creating a New Version of a Label Once 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 Versions To 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 Terms To 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 Qualifications AERS 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.
Managing company product information 5-15
Product Labels
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
Activating a Label When 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:
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.
5-16 Oracle Adverse Event Reporting System Administrator’s Guide
Product Labels
Field / Button
Result
Apply to Selected Labels
Button. Clicking the Apply to Selected Labels button applies the date to the effective date to any selected labels.
3.
Select the Check radio button and click Run to run the TMS check mode. ■
4.
Select the Activate radio button and click Run to activate the label. ■
5.
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.
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.
Click Summary to return to the Product Labels screen, or click Exit to close the screen.
Copying an Existing Label You 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.
Managing company product information 5-17
Product Labels
5-18 Oracle Adverse Event Reporting System Administrator’s Guide
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.
Conceptual Overview Oracle 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 Implementation AERS 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 Implementation Oracle 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
Maintaining the AERS-TMS Dictionary 6-1
Adding Company Products
well as simplify the management of the AERS Company Product Repository (see "Company product repository" on page 2-1).
Regulatory Group Name The 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 Name The 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 Type The 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 Flag The 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 Products Each 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 6-2 Oracle Adverse Event Reporting System Administrator’s Guide
Adding Company Products
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. Maintaining the AERS-TMS Dictionary 6-3
Adding Company Products
Adding a New Regulatory Group Name You 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 Name You 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 Name If your company product already has a preferred name in WHO-DRUG, you can associate that existing name with your Regulatory Group Name. 6-4 Oracle Adverse Event Reporting System Administrator’s Guide
Adding Company Products
To assign an existing preferred name, to a 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.
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.
4.
Enter the AERS Product Type (DRUG, DEVICE, VACCINE) and Blinded Therapy Type (B for blinded therapy, P for placebo).
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: ■
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 Synonym in the Term field in the top block and press Tab. The Synonym details appear. Press Save again to store the relationship.
Maintaining the AERS-TMS Dictionary 6-5
Adding Company Products
Assigning an existing Synonym (Trade Name) to your Regulatory Group Name If 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 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.
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 Name The 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.
4.
Enter the AERS Product Type (DRUG, DEVICE, VACCINE) and Blinded Therapy Type (B for blinded therapy, P for placebo).
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: ■
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.
6-6 Oracle Adverse Event Reporting System Administrator’s Guide
Using TMS Domains
■
■
7.
Enter the Company Product Name in the Term field in the top block and press Tab. The Company Product Name details appear. Press Save again to store the relationship.
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 terms Once 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 Domains A 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 TMS To 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 Domain Once 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, Maintaining the AERS-TMS Dictionary 6-7
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 Objects A 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 Reclassify Batch 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
6-8 Oracle Adverse Event Reporting System Administrator’s Guide
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.
Maintaining the AERS-TMS Dictionary 6-9
Running Batch Reclassify
6-10 Oracle Adverse Event Reporting System Administrator’s Guide
7 Studies The section describes how to manage studies.
Maintaining Study Attributes The 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: 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.
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.
Studies
7-1
Adding Studies
Study Security You 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 Products On 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 Studies To 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.
4.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS adds the study to the database.
Updating Studies To update a study: 1.
Select the Study tab from the Oracle AERS Global Maintenance subsystem. The Study Maintenance screen displays.
2.
Select the study you want to update.
3.
Key in the appropriate changes.
4.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the updates to the database.
Deleting Studies 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.
To delete a study: 7-2 Oracle Adverse Event Reporting System Administrator’s Guide
Deleting Studies
1.
Select the Study tab from the Oracle AERS Global Maintenance subsystem. The Study Maintenance screen displays.
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
4.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS deletes the study from the database.
Studies
7-3
Deleting Studies
7-4 Oracle Adverse Event Reporting System Administrator’s Guide
8 Product 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 Groups You 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. Note: Product Group maintenance is performed in the Global Maintenance subsystem.
Adding Product Groups To 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.
Product Groups 8-1
Updating Product Groups
5.
Press the Save button or F10 to save changes. 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.
8.
Click the Save button or press the F10 key to save changes. The new Product group with its associated Product Codes/Studies is saved to the database.
Updating Product Groups To update a Product Group: 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.
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.
4.
Click the Save button or press the F10 key to save changes. The new Product group with its associated Product Codes/Studies is saved to the database.
Deleting Product Groups 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.
To delete a Product Group, you must first delete the Product Codes associated with the group, then delete the group itself: 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.
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
8-2 Oracle Adverse Event Reporting System Administrator’s Guide
Deleting Product Groups
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.
5.
Click the Save button or press the F10 key to save changes. The Product Group is deleted from the database.
Product Groups 8-3
Deleting Product Groups
8-4 Oracle Adverse Event Reporting System Administrator’s Guide
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.
Overview of multilingual architecture Oracle 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.
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.’
Note:
Maintaining AERS Local Languages The 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.
Configuring AERS for multilingual use
9-1
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.
■
5.
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.
Save you changes.
Setting a User’s Local 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. 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 Translations Oracle 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.
9-2 Oracle Adverse Event Reporting System Administrator’s Guide
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.
6.
Save your changes.
Maintaining Field and Window Label Translations Field 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 Translations To 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.
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.
Note:
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.
Configuring AERS for multilingual use
9-3
Maintaining Error Messages and Translations
Adding Window Label Translations To 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.
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:
5.
Enter the local language translation for the Window Label. ■
Language Code: Enter the local language code as created above.
■
Window Label: Enter the local language translation of the screen label.
6.
Save your changes by pressing F10.
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 Translations Error messages can also be translated into your user’s local languages to assist in the usability of Oracle AERS.
Adding Error Message Translations To 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.
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.
Note:
4.
Enter the local language translation for the error message. ■
Language Code: Enter the local language code as created above.
■
Error Message: Enter the local language translation of the error message.
9-4 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining Error Messages and Translations
5.
Save your changes by pressing F10.
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.
Configuring AERS for multilingual use
9-5
Maintaining Error Messages and Translations
9-6 Oracle Adverse Event Reporting System Administrator’s Guide
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 statuses Oracle 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.
Supporting your work processes 10-1
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
■
■
4.
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.
Click the Save button or press the F10 key to save changes. 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
10-2 Oracle Adverse Event Reporting System Administrator’s Guide
Document templates
(’MEDICAL-REVIEW’, ’DE COMPLETE’, NULL, ’Y’); 3.
Commit your changes.
Action items Action 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 templates A 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. 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.
Note:
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.
Supporting your work processes 10-3
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 template Once 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 <program name>.psp For example: loadpsp -replace -user aers1/aers1@aers45 AECaseSummaryListing.psp
Defining the template in the LETTERS table The 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.
10-4 Oracle Adverse Event Reporting System Administrator’s Guide
Workflow tasks
Workflow tasks Workflow 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. 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.
Note:
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. Supporting your work processes 10-5
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 tasks Prerequisites: ■
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:
10-6 Oracle Adverse Event Reporting System Administrator’s Guide
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.
7.
Click the Save button.
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. Supporting your work processes 10-7
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 users Workflow 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 screens The 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.
10-8 Oracle Adverse Event Reporting System Administrator’s Guide
Designing screens
Global screens and fields configuration The 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 Description The 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
Y
Code list, used to populate record group
FIELD VALIDATION CODE_LIST
CODE_LST_SOFT_VAL_ Y FLAG
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
Supporting your work processes 10-9
Designing screens
Table 10–1 (Cont.) Field Attributes Table Field Name
Mod?
Description
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?
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).
VISUAL CONTROLS
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.
10-10 Oracle Adverse Event Reporting System Administrator’s Guide
Designing screens
Table 10–1 (Cont.) Field Attributes Table Field Name
Mod?
Description
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.
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_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
QUERY FIELDS
CUSTOM COMMENTS
CUSTOM_COMMENTS_ Y TEXT
Text describing customization
N
Custom permission type S (System), C (Customer may modify)
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
CUSTOM_PERMSN_ TYPE AUDIT INFORMATION
WDW_ATTRIBUTES Table Description The 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. Table 10–2
Window Attributes Table
Field Name
Mod?
Description
CURRENT_WDW
N
Current window. There are entries here for the main windows as well as the subtabs.
Supporting your work processes 10-11
Designing screens
Table 10–2 (Cont.) Window Attributes Table Field Name
Mod?
Description
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
Modifying the global screens and fields configuration attributes 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, or by selecting Help=>FAT Configuration. The Field Attributes window displays. 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.
Note:
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.
4.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the changes to the database.
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. ■
3.
Window Label: The label that appears on the tab stop
Click the Save button or press the F10 key to save changes. Oracle AERS saves the changes to the database.
Revealing custom fields The custom screens and fields are hidden by default, to reveal them follow these directions: 1.
From Case Browse, select Help=>FAT Configuration.
10-12 Oracle Adverse Event Reporting System Administrator’s Guide
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. 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.
Note:
Workflow-specific screens and fields configuration For 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 Table The 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. Table 10–3
Field Modes 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
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
WINDOW_MODES Table Properties of windows for different Workflow Tasks. There must be an entry for every Workflow Task for every Data Entry window in the WAT.
Supporting your work processes 10-13
Configuring the data entry Navigator panel
Table 10–4
Window Modes Table
Field Name
Mod?
Description
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
Modifying Workflow-specific screen and field configuration To 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.
■
■
■
■
■
■
■
4.
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.
Click the Save button or press the F10 key to save changes.
Configuring the data entry Navigator panel The 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.
10-14 Oracle Adverse Event Reporting System Administrator’s Guide
Configuring the data entry Navigator panel
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 entry For 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.
5.
Key in all fields. ■
6.
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
Click the Save button or press the F10 key to save changes. The new tree name is saved to the database.
Creating Record Groups The 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 Supporting your work processes 10-15
Configuring the data entry Navigator panel
■
4.
Lov Name:, not used.
Click the Save button or press the F10 key to save changes. The new tree name is saved to the database.
Creating the SQL statement to display the Navigator view The definition and use of the column is as follows: Column 1: Default Node expansion. Values
Description
1
Expand the node
-1
Collapse the node
0
An end node (not expandable
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. This is sorted as an alpha (character) value so A12 sorts before A2.
Note:
■
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',
10-16 Oracle Adverse Event Reporting System Administrator’s Guide
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. The use of A1 and A2 in the Union’d statements; these control the sort order within the full tree.
Note:
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 constraints It 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).
Supporting your work processes 10-17
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.
10-18 Oracle Adverse Event Reporting System Administrator’s Guide
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 security The 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 objects You can set security on the level of the Oracle AERS sites, user groups, and users.
User groups You 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 Managing Users And User Groups 11-1
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.
Users You 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 security The 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 ownership Every 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 permissions Every 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.
11-2 Oracle Adverse Event Reporting System Administrator’s Guide
Managing Oracle AERS Roles
Oracle Roles Oracle 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/Groups AERS 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 Roles Oracle 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 users Oracle 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 Roles Oracle 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 Managing Users And User Groups 11-3
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. This feature differs from previous releases of AERS, in which you could only confer supervisor privileges by granting the reserved role SUPERVISOR.
Note:
■
■
■
4.
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.
Click the Save button, or press the F10 key, to save the role. Oracle AERS saves the role to the database.
Maintaining user groups A 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). You perform user group maintenance in the local Oracle AERS application.
Note:
This section describes the following user group maintenance tasks: ■
Understanding user group permissions
11-4 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining user groups
■
Adding permissions to a user group
■
Adding user groups
■
Updating user groups
■
Deleting user groups
Understanding user group permissions You 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. 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
Adding permissions to a user group To 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. 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.
Note:
Adding user groups To add a user group: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
2.
Select the User Profile tab from the Administrator Console. Managing Users And User Groups 11-5
Maintaining user groups
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. ■
■
■
5.
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.
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 groups To update a user group: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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 groups You 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").
11-6 Oracle Adverse Event Reporting System Administrator’s Guide
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.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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 users As 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 users AERS 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.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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.
Managing Users And User Groups 11-7
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 passwords When 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 roles Users 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 Roles Every 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.
11-8 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining users
Table 11–2 (Cont.) Baseline Oracle Roles Menu Role
Visible Menus/Permissions
COMMON_MENU_ ENRL
Gives the minimum menu bar: File=>Print Screen, Exit, Window (all), Help (all). Data Mnt=>Change Password (all): All users must have this.
(Oracle menu role)
Optional AERS Roles Table 11–3 lists the optional Oracle Menu Roles you can assign, according to job definition. Table 11–3
Oracle AERS Roles
Menu Role
Visible Menus/Permissions
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
Managing Users And User Groups 11-9
Maintaining users
Table 11–3 (Cont.) Oracle AERS Roles Menu Role
Visible Menus/Permissions (Cont.)
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
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. Menu Role
Permissions
ENREAD
Grants read-only access to Oracle AERS tables for ad hoc query capability (see Ad Hoc section below).
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.
Note:
Other AERS Application Roles Oracle 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. 11-10 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining users
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 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: 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.
Assigning roles to a user The 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: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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.
Managing Users And User Groups
11-11
Maintaining users
Updating user attributes and permissions To update a Oracle AERS user profile: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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.
11-12 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining users
Table 11–4 (Cont.) User Attributes and Permissions Option
Description
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.
5.
Click the Save button, or press F10, to save changes. The system saves the user to the database.
User permissions You 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. 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
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. 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.
Note:
Managing Users And User Groups
11-13
Local privacy and security
Local privacy and security Oracle 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 membership The 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 configuration The 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.
11-14 Oracle Adverse Event Reporting System Administrator’s Guide
Local privacy and security
Example 1: Local Privacy configuration for patient name and address In 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 data In 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.
Managing Users And User Groups
11-15
Record-level filtering
Configuration Procedure Creating the Codelist For 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:
3.
4.
■
Enter the Codelist Name and Description.
■
Set the Customization Type to “C” for customizable.
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.
Save the Codelist.
Configuring the Security Codelist To 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.
5.
Save your changes.
Record-level filtering Oracle 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.
11-16 Oracle Adverse Event Reporting System Administrator’s Guide
Record-level filtering
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 components There are three components to the record-level filtering configuration: Authorization Lists These 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 Tasks Any 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 affiliate In 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.
Managing Users And User Groups
11-17
Record-level filtering
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). 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:
Example 2: Investigation filtering for Product Complaint investigation users In 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). 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.
Note:
Configuration Procedure Filtering Records To 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
11-18 Oracle Adverse Event Reporting System Administrator’s Guide
Record-level filtering
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 List The 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.
3.
■
Enter the Codelist Name and Description.
■
Set the Customization Type to “C” for customizable.
Enter codelist values. ■
Enter the names of the Assigned To values as the Code.
■
Enter the Language Code “en”. Managing Users And User Groups
11-19
Record-level filtering
■
Set the User Enterable flag to ’Y’.
■
The Retired Flag should be ’N’.
■
4.
The values of the other attributes are optional.
Save the Codelist.
Creating Roles You 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: –
■
For an Investigations authorization list: –
5.
Set the Country List Flag to ’Y’ for the role.
Set the Assignment Flag to 'Y' for the role.
Save your Role(s).
Assigning Roles Once 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 Task Assigning 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.
11-20 Oracle Adverse Event Reporting System Administrator’s Guide
Managing passwords
Managing passwords Oracle 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 passwords You 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: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
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.
2.
Select the user from the Navigator panel.
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 Users And User Groups
11-21
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 timeout Oracle 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: 1.
Navigate to the Administrator Console.
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. ■
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. ■
5.
Under Control Value, enter the time in seconds.
Under Control Value, enter the time in seconds.
Close the Administrator Console.
Resetting a user’s password Resetting a password using the Administrator Console Users with administrator privileges can reset another user’s password from within the Administrator Console. To reset a user’s password using the Administrator Console: 1.
Navigate to the Administrator Console.
2.
Select the user from the Navigator panel.
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. Note: The default password is <username123>. See "Assigning Oracle passwords"for more information.
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. 11-22 Oracle Adverse Event Reporting System Administrator’s Guide
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*Plus If 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 Password There are four steps to changing the PORTAL30 password for AERS: 1.
2.
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;
c.
Exit SQL*Plus.
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 Users And User Groups
11-23
Managing passwords
3.
4.
c.
Click on the Change Password link at the top right hand side of the page.
d.
Enter the old password and the.
e.
Click OK.
f.
Close the browser.
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/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.
Change the stored password for PORTAL30 on the Report Server. a.
Login to the Report Server machine.
b.
Navigate to the\reports\conf directory.
c.
Copy the.conf file to .old.
d.
Open the.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 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 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.
11-24 Oracle Adverse Event Reporting System Administrator’s Guide
12 Data 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 codes Every 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 view You 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 CASE_ID
Value
Description Case ID
Data management 12-1
Duplicate checking
Column Name
Value
Description
VERSION NUMBER
Number
Version #
Duplicate checking Oracle 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 API This section describes what the Duplicate Check API function does, its input parameters, and what it produces as output.
Description The 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 parameters Table 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. 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
12-2 Oracle Adverse Event Reporting System Administrator’s Guide
Duplicate checking
Table 12–1 (Cont.) Input Parameters Parameter
Data
Description
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
Output The 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 logic Duplicate 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 Data management 12-3
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 Cases Clinical 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
12-4 Oracle Adverse Event Reporting System Administrator’s Guide
Copy Case
Product Complaint Cases The 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 Field
Value if Matched
Product Code
2.0
Complaint Code
1.0
Lot Number
1.0
Reporter Last Name (first three letters)
1.0
Copy Case The front-end calls Copy Case, which AERS defines in the function DECopyCase. FUNCTION:
DECopyCase
INPUT:
Case ID, New Case ID
OUTPUT:
Inserts data into tables specified in function.
Generic implementation Table 12–2 lists the data elements that the copy case function copies. Table 12–2
Copy Case Data Elements
Copied Table
Copied Columns
AE_CASES
CASE_ID
DRUG_FORM
CASE_STS
DRUG_DID
CASE_TYPE
DRUG_PROJECT_TID
PROCESS_FLAG
DICT_UNMAPD_FLAG
DELETE_FLAG
GENERIC_NAME
FIRST_RCVD_DT
DRUG_CLASS
VALIDATION_REQD_FLAG
PREFERRED_DRUG_PROJECT_NAME
RECONCILIATION_STS
RISK_FACTOR_CMNT
PROD_CD
PER_SFTY_UP_RPT_CMNT
CASE_OWNER_USR_GRP_ID
PHARMACOVIGILANCE_CMNT
PROJECT_DRUG_NAME
EV_OCC_COUNTRY_CD
Data management 12-5
Copy Case
Table 12–2 (Cont.) Copy Case Data Elements Copied Table
Copied Columns (Cont.)
AE_EVENTS
CASE_ID
CO_ADDED_TERM_FLAG
EVENT_SEQ_NBR
SERIOUS_FLAG
DISPLAY_NBR
FROM_DT
PRIMARY_IND
TO_DT
RPT_VERBTM
ONGOING_FLAG
CO_VERBTM
DURATION
PREFERRED_EVENT_TERM
DURATION_UNIT
BODY_SYSTEM
OUTCOME_CD
SUB_BODY
THERAPY_FLAG
MID_LVL_TERM
THERAPY_TEXT
EVENT_DID
US_UNEXPECTED_FLAG
EVENT_TID
CORE_UNEXPECTED_ FLAG
DICT_UNMAPD_FLAG AE_SUSPECT_ DRUGS
CASE_ID
CUM_DOSE
SUSP_DRG_SEQ_NBR
CUM_DOSE_UNIT
DRUG_NAME
ABATE_FLAG
DRUG_DID
REAPPEARED_FLAG
SUSPECT_DRUG_TID
PRIOR_USE_FLAG
DICT_UNMAPD_FLAG
TOLERATED_FLAG
GENERIC_NAME
RECHALLENGED_FLAG
DRUG_CLASS
DUR_OF_TRTMT_TO_EV
PREFERRED_DRUG_NAME
DUR_OF_TRTMT_TO_EV_UNIT
DISPLAY_NBR
TOTAL_DUR_OF_TRTMT
PRIMARY_FLAG
TOTAL_DUR_OF_TRTMT_UNIT
DRUG_COMPANY_FLAG
ROUTE_CHILD_CD
OVER_COUNTER_FLAG
PURCH_COUNTRY_CD
ACTION_TAKEN
DRUG_INTERACTION_FLAG
REASON_FOR_ACTION
REPORTER_CAUSE_TYPE
LOT_NBR
RELATEDNESS_CD
EXP_DT
RPT_RELATEDNESS_CD
NDC_NBR
CUM_DOSE_CHR
PRODUCT_PROBLEM_FLAG PROD_PROB_QA_NUMBER AE_INDICATIONS
CASE_ID
INDICATION_CODE
SUSP_DRG_SEQ_NBR
DX_DID
INDIC_SEQ_NBR
INDICATION_TID
INDICATION
DICT_UNMAPD_FLAG
12-6 Oracle Adverse Event Reporting System Administrator’s Guide
Copy Case
Table 12–2 (Cont.) Copy Case Data Elements Copied Table
Copied Columns (Cont.)
AE_DOSAGES
CASE_ID
DOSE_STRENGTH
SUSP_DRG_SEQ_NBR
DOSE_STRENGTH_UNIT
DSG_SEQ_NBR
FROM_DT
DOSE
TO_DT
DOSE_UNIT
DURATION
FREQUENCY
DURATION_UNIT
ROUTE
CLOSEST_TO_EV_FLAG
DRUG_FORM
DOSE_CHR DOSE_STRENGTH_CHR
AE_EVENTS_TO_ DRGS
CASE_ID
RPT_RELATEDNESS_CD
SUSP_DRG_SEQ_NBR
US_UNEXPECTED_FLAG
EVENT_SEQ_NBR
CORE_UNEXPECTED_FLAG
RELATEDNESS_CD AE_CASE_RPT_ FRM_LOGS
CASE_ID
PREP_BY_COMPANY
CS_LOG_SEQ_NBR
PREP_BY_CITY_NAME
RCVD_DT
PREP_BY_COUNTRY_CD
RCVD_BY_FRST_NAME
PROCESSED_IN_SFTY_DT
RCVD_BY_LST_NAME
REV_FRST_NAME
RCVD_BY_POSITION
REV_LST_NAME
PREP_DT
REVIEW_DT
PREP_BY_FRST_NAME
LOG_IN_COMMENTS_TEXT
PREP_BY_LST_NAME
Data management 12-7
Data derivation procedures
Table 12–2 (Cont.) Copy Case Data Elements Copied Table
Copied Columns (Cont.)
AE_REPORT_ SOURCES
CASE_ID
RPT_ORG_NAME
RPT_SEQ_NBR
RPT_ADDR1
PRINCIPAL_INVEST
RPT_ADDR2
NON_CO_STUDY_SPONSOR
RPT_ADDR3
RPT_SOURCE_TYPE
RPT_ADDR4
REGISTRY_NAME
RPT_CITY_NAME
REGISTRY_NBR
RPT_STATE_CD
LITERATURE_DESC
RPT_ZIP_CD
LIT_ISSUE_DT
RPT_COUNTRY_CD
LIT_VOLUME
RPT_PHONE
LIT_PAGE
RPT_FAX
RPT_ID
RPT_EMAIL
NON_CO_STUDY_DESC
RPT_OCCUPATION
RPT_FRST_NAME
RPT_SPECIALTY_DESC
RPT_LST_NAME
WRK_HOSP_FLAG
RPT_MID_INITIAL
RPT_IS_PATIENT_FLAG
RPT_TITLE
OTHER_PATIENT_ID
HEALTH_PROF_FLAG CONSUMER_FLAG PRIMARY_REPORTER_IND AE_RLVNT_ APPROVALS
CASE_ID
LIC_NBR
SUSP_DRG_SEQ_NBR
LIC_TYPE
RLVNT_APPR_SEQ_NBR VW_COMPANY_ NARRATIVE, VW_REPORTER_ NARRATIVE
CASE_ID FIELD_NAME FIELD_VALUE
Data derivation procedures Oracle AERS provides two data derivation procedures: Case ID generation and Case data derivations.
Case ID generation An 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.
12-8 Oracle Adverse Event Reporting System Administrator’s Guide
Data derivation procedures
Updating the Case ID generation algorithm Function Name
GENERATECASEID
Return Type
VARCHAR32
Input
None
Output Description
Unique Case ID
Case data derivations The 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 derivations The 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 library The 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 Data management 12-9
Data derivation procedures
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. 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.
Generating the library To 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.
12-10 Oracle Adverse Event Reporting System Administrator’s Guide
Data derivation procedures
Standard derivation procedures Table 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
Fld: Field derivation triggers the derivation. EN: The derivation is not customizable (Core). Stored: Oracle AERS stores the derivation result in the database.
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."
Data management 12-11
Data derivation procedures
Table 12–4 (Cont.) Standard Derivation Procedures Field (Cont.)
Source Fields (Cont.)
Description
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
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.
Event Level Seriousness, Unexpectedness
Any 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.
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
Fld: Field derivation triggers the derivation. EN: The derivation is not customizable (Core). Stored: Oracle AERS stores the derivation result in the database.
MOD_REPORTER_ CAUSE
REPORTER_CAUSE_ TYPE
Fld: Field derivation triggers the derivation. EN: The derivation is not customizable (Core). Stored: Oracle AERS stores the derivation result in the database.
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."
12-12 Oracle Adverse Event Reporting System Administrator’s Guide
Field code lists
Table 12–4 (Cont.) Standard Derivation Procedures Field (Cont.)
Source Fields (Cont.)
Description
Reconciliation Discrepancy
Existence of under Review Cust: The derivation is customizable. PLL: Oracle AERS stores the derivation logic in the Forms Reconciliation library. Discrepancy 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_ Rec: The Record-level triggers the derivation. RPT_ FRM_LOGS records. 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."
Field code lists You 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
Data management 12-13
Field code lists
Adding new code lists If 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 list To add a code list to the Oracle AERS Code List tables: 1.
Launch the Oracle AERS Global Maintenance subsystem.
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. 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.
Note:
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 items To 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
12-14 Oracle Adverse Event Reporting System Administrator’s Guide
Field code lists
AERS also includes specific, reserved languages (RPT, E2B, ISO, and UPL) for coding purposes. ■
■
■
■
6.
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.
Click the Save button, or press F10, to save changes. Oracle AERS saves the new code list item to the database.
Step 3: Create a Record Group Oracle 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.
4.
Click the Save button, or press F10, to save changes.
5.
Close the window.
6.
Exit the Field Attributes form (if done).
Step 4: Assigning code lists to fields To 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.
Data management 12-15
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.
5.
Click the Save button.
Define LOV Column Mapping Once 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 lists In 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
12-16 Oracle Adverse Event Reporting System Administrator’s Guide
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. The Field Attributes form displays.
Updating existing code lists You 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 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.
Updating an item in a code list To update an item in a code list: Data management 12-17
Field code lists
1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab. The Code List Maintenance screen displays.
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.
6.
Click the Save button, or press F10, to save changes. Oracle AERS saves the changes to the database.
Retiring code list values You 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: 1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab from the main window. The Code List Maintenance screen displays.
3.
Select the code list containing the code you want to retire. The code information displays.
4.
Select the code you want to retire.
5.
Click the Retired checkbox to display a check mark.
6.
Click the Save button, or press F10, to save changes.
Reactivating retired individual code list items To reactivate a retired item in a code list: 1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab from the main window. The Code List Maintenance screen displays.
3.
Select the code list containing the code you want to reactivate. The code information displays.
4.
Select the code you want to reactivate.
5.
Click the Retired checkbox to remove the retired check mark.
6.
Click the Save button, or press F10, to save changes.
Deleting code lists To delete a code list: 12-18 Oracle Adverse Event Reporting System Administrator’s Guide
Edit checks
1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab from the main window. The Code List Maintenance screen displays.
3.
Select the code list you want to delete.
4.
Click the Delete button. The code list disappears from the screen.
5.
Click the Save button, or press F10, to save changes. 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 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.
To delete an item in a code list: 1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab from the main window. The Code List Maintenance screen displays.
3.
Select the code list containing the code you want to delete.
4.
Click the Delete button. The code disappears from the screen.
5.
Click the Save button, or press F10, to save changes. Oracle AERS does not prompt you, and deletes the code list value from the database.
Edit checks Edit 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 checks Field 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
Data management 12-19
Edit checks
checks must be performed at the record-or case-level (wherever is appropriate to that check). Record checks Record checks fire when the user modifies any data in a record and shifts the focus outside the record. Case Save Case Save fires when the user has modified any data in the case and explicitly invokes the save option. Case Exit Case 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 Checking This process runs in the background from the Oracle AERS batch edit report. All Soft edit checks fire in batch mode.
Updating the edit check program You 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 12–5
CustomEditRules Parameters
Parameter
Data Type
Description
ivRecordString/ IN VARCHAR2 ivCaseID
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)
IonGrandChildS IN OUT eq Nbr 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
Table descriptions This section describes the RULE_ATTRIBUTES table and the RULE_FIRING_MODES table. 12-20 Oracle Adverse Event Reporting System Administrator’s Guide
Edit checks
RULE_ATTRIBUTES table The 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. 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)
RULE_FIRING_MODES table This table contains Workflow Tasks in which the rule fires. This table is an intersection table between RULE_ATTRIBUTES and DATA_ENTRY_MODES. 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.
Note:
Table 12–7
RULE_FIRING_MODES Table
Field Name
Description
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)
Data management 12-21
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. 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
(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. TABLE_NAME
RULE_NAME
DE_MODE
RECORD_STS
AE_CASE_RPT_FRM_ LOGS
PREP_DATE_AFTER_ RCVD_ DATE
LOGIN
N
AE_CASE_RPT_FRM_ LOGS
PREP_DATE_AFTER_ RCVD_ DATE
LOGIN
U
AE_CASE_RPT_FRM_ LOGS
PREP_DATE_AFTER_ RCVD_ DATE
DE
U
AE_CASE_RPT_FRM_ LOGS
PREP_DATE_AFTER_ RCVD_ DATE
ASSESS
U
Spell Check The standard Oracle AERS configuration supports spell check using Microsoft Word from a user’s desktop machine via ActiveX. Oracle AERS is also configured to
12-22 Oracle Adverse Event Reporting System Administrator’s Guide
Spell Check
integrate with JSpell. However, it must be purchased by your company and installed on the server.
Configuring for Microsoft Word If 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. 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.
Installing JSpell in Oracle AERS This 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. <806_Home> is the Oracle 806 Home of the 9iAS, e.g. D:\Oracle\806)
Note:
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
Data management 12-23
Reconciliation
■
log=<806_Home>\\FORMS60\\java\\jspell.log Note:
5.
In the\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): ■ ■
■
6.
7.
The double back-slashes are required (for this file only).
#JSpell servlet.jspell.initArgs=propertiesFile=<806_ Home>\forms60\server\jspell.properties servlet.jspell.code=com.wallstreetwise.app.jspell.domain.net.JSpellServlet
In directory\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
Restart the Apache Server (OracleiSuitesHTTPServer) on the 9iAS application server.
AS10g Forms Server configuration Edit the file formsweb.cfg in directory\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:
1.
■
2.
archive_jini= f90all_jinit.jar,opaicons.jar,aersicons.jar,timeout.jar,jspell2n_ java11.jar, JSpellIntegration.jar
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.
Reconciliation The 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 Reconciliation You 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.
12-24 Oracle Adverse Event Reporting System Administrator’s Guide
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.
Data management 12-25
Reconciliation
Table 12–8 (Cont.) Reconciliation Rules Rule Name
Condition
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.
Staging tables The 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 table This reconciliation table contains the case information for the patient. Table 12–9
RCN_CASES Table
Field Name
Description
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
12-26 Oracle Adverse Event Reporting System Administrator’s Guide
Reconciliation
Table 12–9 (Cont.) RCN_CASES Table Field Name
Description
CENTER_ID
Code corresponding to the Study Center where the patient was treated
RCN_PATIENT table This reconciliation table contains the patient information. Table 12–10
RCN_PATIENT Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
STUDY_ID
Enrolled study/protocol number
CENTER_ID
Code corresponding to the Study Center where the patient was treated
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
RCN_PATIENT_VITALS table This reconciliation table contains vitals about the patient such as height and weight.
Data management 12-27
Reconciliation
Table 12–11
RCN_VITALS Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
STUDY_ID
Enrolled study/protocol number
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
RCN_PT_AE_PROFILE table This reconciliation table contains patient adverse event information. Table 12–12
RCN_PT_AE_PROFILE Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
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
12-28 Oracle Adverse Event Reporting System Administrator’s Guide
Reconciliation
Table 12–12
(Cont.) RCN_PT_AE_PROFILE Table
Field Name
Description
RELATEDNESS_CD
Indicates an assessment as to whether the symptom or diagnosis is related to the suspect drug
RCN_PT_CAUSE_DEATH table This reconciliation table contains patient cause of death. Table 12–13
RCN_PT_CAUSE_DEATH Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
STUDY_ID
Enrolled study/protocol number
CENTER_ID
Code corresponding to the Study Center where the patient was treated
CAUSE_OF_DEATH_ CODE
The ICD code for the cause of death
CAUSE_OF_DEATH
Text describing the cause of death
RCN_PT_DOSING table This reconciliation table contains patient dosing information. Table 12–14
RCN_PT_DOSING Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
STUDY_ID
Enrolled study/protocol number
CENTER_ID
Code corresponding to the Study Center where the patient was treated
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
Data management 12-29
Clinical data extract file
Table 12–14
(Cont.) RCN_PT_DOSING Table
Field Name
Description
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
Clinical data extract file The 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:
12-30 Oracle Adverse Event Reporting System Administrator’s Guide
Clinical data extract file
Column_Name1,,Column_Name3.
Coded field translations Oracle 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 program Clinical 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.
Data management 12-31
Clinical data extract file
12-32 Oracle Adverse Event Reporting System Administrator’s Guide
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
Overview The Case Browse configuration is managed in four tables: Code Lists, Data Entry Modes, Field Attributes, and Field Modes.
Modes Each 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:
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.
Field Attributes The 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:
Configuring Case Browse
13-1
Overview
Attributes
Req?
Description
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.
Relevant Field Modes Each 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:
Attributes
Req?
Description
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
13-2 Oracle Adverse Event Reporting System Administrator’s Guide
Adding or Updating a Custom Browse Configuration
Adding or Updating a Custom Browse Configuration To 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: ■
■
2.
Code: Name of the Case Browse Mode (e.g. BRW-). 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.
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. Note:
You should only perform this step when users are off the
system.
6.
a.
Launch the Workflow Configuration form from the AERS Home Page.
b.
Select Rebuild Browse Config from Actions menu
c.
Exit Workflow Configuration
Configure the Default Case Browse for each user using the User administration screen on the AERS Administration Console.
Fields Available for Configuration The following Field Attributes items are available for Case Browse Configuration:
ITEM_NAME
TABLE_NAME
FIELD_NAME
SCREEN_LABEL
ACIS_FLAGS
AE_CASES
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
ACIS
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
PT_RACE
AE_CASES
Age PT_RACE_CD
13-4 Oracle Adverse Event Reporting System Administrator’s Guide
Race
Fields Available for Configuration
ITEM_NAME
TABLE_NAME
FIELD_NAME
SCREEN_LABEL
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
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
INITIAL_RECEIVE_DATE EC_CONTACT_LOG
Serious
Init/Follow-up 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
Configuring Case Browse
13-5
Out-of-the-Box Case Browse Configuration
ITEM_NAME
TABLE_NAME
FIELD_NAME
SCREEN_LABEL
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#
Out-of-the-Box Case Browse Configuration There 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;
Field Attributes
Item Name
Field Modes
Table Name
Field Name
Dic Query Text
BRW DEFAULT: Default modes
13-6 Oracle Adverse Event Reporting System Administrator’s Guide
Sub Query Text
X Pos
Y Pos
Field Wdth
Out-of-the-Box Case Browse Configuration
Field Attributes
Item Name
Field Modes
Table Name
Field Name
Dic Query Text
Sub Query Text
SORT_SEQ_ NBR
X Pos
Y Pos
Field Wdth
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
481
59
63
PROD_CD
AE_CASES
543
59
98
162
70
30
NEXT_ TASK_ DUE
192
70
75
AE_CASES EV_OCC_ COUNTRY_CD
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 405 CONTAC T_SEQ_ NBR
70
76
CORE_ AE_CASES UNEXPECTED _ FLAG
CORE_ UNEXPEC TED_ FLAG
481
70
32
US_ AE_CASES UNEXPECTED _ FLAG
US_ UNEXPEC TED_ FLAG
513
70
31
CO_VERBTM
CO_ VERBTM
543
70
98
decode(DIED_ FLAG,'Y','DEATH ',decode(LF_ THREAT_ FLAG,'Y', 'LIFETHREAT',de code(SERIOUS_ FLAG,'Y','SERIO US','N','NOT-SERI OUS',NULL))) PROD_CD
PICKED_FLAG NEXT_TASK_ DUE
VW_NEXT_ TASK
AE_EVENTS
and DISPLAY _NBR = 1
Configuring Case Browse
13-7
Out-of-the-Box Case Browse Configuration
Field Attributes
Field Modes
Item Name
Table Name
ACIS_FLAGS
AE_CASES
PRIORITY
AE_CASES
Field Name
Dic Query Text
Sub Query Text
X Pos
Y Pos
Field Wdth
162
81
30
CASE_ PRIORITY
192
81
75
RPT_SOURCE_ TE_ TYPE PREFERRED_ SOURCE
PREFERRE D_ SOURCE
267
81
77
PATIENT_ID
AE_CASES
PATIENT_ ID
344
81
61
RECEIVED_ DATE
EC_CONTACT_ LOG
405
81
76
REPORTER_ CAUSE_ TYPE
AE_CASES
REPORTE R_CAUSE_ TYPE
481
81
63
EV_ONSET_ DATE
AE_CASES
EV_ ONSET_ DT
543
81
98
162
59
30
decode(ADVERS E_EVENT_FLAG, 'Y','A') || decode( PRODUCT_ COMPLAINT_ FLAG,'Y', 'C') || decode(MEDICA L_ INQUIRY_ FLAG, 'Y','I') || decode( SERVICE_ COMPLAINT_ FLAG,'Y','S')
max(RECEIVE_ DATE)
BRW-PC: Complaints SORT_SEQ_ NBR 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
344 decode(count(*),0, and 'N','Y') DATE_ COMPLE TED is NULL
59
76
420
59
76
OPEN_ TE_ CORRECTIVE_ CORRECTIVE_ ACTIONS ACTIONS
CASE_STS
AE_CASES
CASE_STS
13-8 Oracle Adverse Event Reporting System Administrator’s Guide
Out-of-the-Box Case Browse Configuration
Field Attributes
Field Modes
Item Name
Table Name
SERIOUS_ FLAG
AE_CASES
PROD_CD
AE_CASES
Field Name
Dic Query Text
Sub Query Text
decode(DIED_ FLAG,'Y','DEATH ', decode(LF_ THREAT_ FLAG,'Y', 'LIFE-THREAT',d ecode( SERIOUS_ FLAG,'Y','SERIO US','N','NOT-SERI OUS',NULL))) PROD_CD
PICKED_FLAG
X Pos
Y Pos
Field Wdth
481
59
63
496
59
145
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_ INVESTIGATI ONS
PC_ INVESTIGATIO NS
344 decode(count(*),0, and 'N','Y') DATE_ COMPLE TED is NULL
70
76
INITIAL_ RECEIVE_ DATE
EC_CONTACT_ LOG
RECEIVE_ DATE
order by 420 CONTAC T_SEQ_ NBR
70
76
CORE_ AE_CASES UNEXPECTED _ FLAG
CORE_ UNEXPEC TED_ FLAG
481
70
32
COMPLAINT_ CODE
COMPLAI NT_CODE
496
70
145
513
70
31
543
70
98
AE_SUSPECT_ DRUGS
US_ AE_CASES UNEXPECTED _ FLAG
US_ UNEXPEC TED_ FLAG
CO_VERBTM
CO_ VERBTM
AE_EVENTS
and DISPLAY _NBR = 1
and DISPLAY _NBR = 1
Configuring Case Browse
13-9
Out-of-the-Box Case Browse Configuration
Field Attributes
Field Modes
Item Name
Table Name
ACIS_FLAGS
AE_CASES
PRIORITY
AE_CASES
RPT_SOURCE_ TE_ TYPE PREFERRED_ SOURCE
Field Name
Dic Query Text
Sub Query Text
X Pos
Y Pos
Field Wdth
162
81
30
CASE_ PRIORITY
192
81
75
PREFERRE D_ SOURCE
267
81
77
decode(ADVERS E_EVENT_ FLAG,'Y','A') || decode(PRODUC T_ COMPLAINT_ FLAG,'Y','C') || decode(MEDICA L_INQUIRY_ FLAG,'Y','I') || decode(SERVICE_ COMPLAINT_ FLAG,'Y','S')
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, and 'N','Y') DATE_ RETURN ED is NULL
344
81
76
RECEIVED_ DATE
EC_CONTACT_ LOG
max(RECEIVE_ DATE)
420
81
76
REPORTER_ CAUSE_ TYPE
AE_CASES
REPORTE R_CAUSE_ TYPE
481
81
63
EV_ONSET_ DATE
AE_CASES
EV_ ONSET_ DT
496
81
145
13-10 Oracle Adverse Event Reporting System Administrator’s Guide
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 configuration This section describes the two principal query configuration tasks: Modifying existing query configuration and Adding new query fields.
Modifying existing query configuration You 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.
Case Data Query 14-1
Query configuration
Table 14–1
Configuring Query Fields
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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.
14-2 Oracle Adverse Event Reporting System Administrator’s Guide
Query configuration
Table 14–3 (Cont.) Configuring Query Appearance Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Case Data Query 14-3
Query configuration
Table 14–8 (Cont.) Query Window Configuration Field Name
Mod?
Description
HELP_CONTEXT_ID
N
Tag to support the help facility
HELP_TEXT
Y
Modifying site
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. The Field Attributes form displays.
2.
Configure the screens and fields by performing one or more of the following tasks: ■ ■
■
■
■
3.
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).
Click the Save button or press the F10 key to save your changes.
Adding new query fields When 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 views In 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. If you link to an external system, you must create a public link and grant READ access to that link to the ENUSER role.
Note:
Once you create the view, you must introduce the join criteria from Oracle AERS to the external view.
14-4 Oracle Adverse Event Reporting System Administrator’s Guide
Query configuration
Adding the Query Table Join The 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. 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.
Note:
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.
5.
Close the window.
Adding a new field to the query screens Once 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. The Field Attributes form displays.
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.
Case Data Query 14-5
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. Caution: DO NOT change the values of the Window Name, Block Name and Item Name. These are not configurable.
5.
Click the Save button, or press the F10 key, to save the newly created field.
Adding an Exclude Flag to a new block The 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: ■
■ ■
4.
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.
Click the Save button, or press the F10 key, to save the newly created field.
Adding custom queries Once 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.
14-6 Oracle Adverse Event Reporting System Administrator’s Guide
Adding custom queries
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 Console To manage user favorites from the Administrator Console: 1.
Navigate to 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.
Case Data Query 14-7
Adding custom queries
14-8 Oracle Adverse Event Reporting System Administrator’s Guide
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 Parameters The 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.
E2B Configuration 15-1
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 processing The 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 Table The 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.
15-2 Oracle Adverse Event Reporting System Administrator’s Guide
Export processing
Flag
Explanation
Action
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 If ‘Y’ the case version is included. version number based If ‘N’, the case version field is left upon workflow events as blank. 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.
USE_LONG_CASEID
The EMEA requires the safetyreportid be a concatenation of three data values, separated by dashes:--
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 If ‘Y’, the reactionmeddraversionpt the tag is included in the output. reactionmeddraversionpt If ‘N’, the tag is not included. tag included in the file.
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.
E2B Configuration 15-3
Export processing
Flag
Explanation
Action
INCLUDE_EDIFACT_ ENVELOPE
This flag modifies the output to meet EDIFact/FDA requirements.
If ‘Y’, The file type suffix is set to.edi instead of the usual.xml.
EFIFACT specific data is added to This option works in the EDI header and trailer. conjunction with the EDI_ Specifically, HEADER and TRAILER. 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.
15-4 Oracle Adverse Event Reporting System Administrator’s Guide
Export processing
Flag
Explanation
Action
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 and included in the Drug Info tag instead
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 and included in the Dosage Text tag instead
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 If ’Y’ and there is no E2B decode for published list, it is output the dose unit it is suppressed from into the drug info field. the dose unit field and included in the Drug Info tag instead
DOSEUNIT_TO_ DOSETEXT
If a dose unit is not in the If ’Y’ and there is no E2B decode for published list, it is output the dose unit it is suppressed from the dose unit field into the dose text field. and included in the Dosage Text tag instead
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
INDICATION_LABEL
The prefix for unmapped This value is prefixed to the indications when they are unmapped indications when they converted to free text. 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
This value is prefixed to the unmapped medical history terms when they are written to the patientmedicalcomment tag.
The prefix for unmapped medical history terms when they are converted to free text.
E2B Configuration 15-5
Import processing
Flag
Explanation
Action
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
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 Y - If a recipient’s gateway is down, the E2B message or the the recipient gateway is acknowledgement is not written to down. 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 AERS 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 15-6 Oracle Adverse Event Reporting System Administrator’s Guide
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.
4.
Click the Save button, or select File=>Save, to save your changes. The sender is saved to the database.
Import Rules This 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_RULES The E2B_IMPORT_RULES table contains the sender-specific import rules configuration. Flag
Explanation
Action
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.
E2B Configuration 15-7
Import processing
Flag
Explanation
USE_SENDER_RECEIVE_ If the sender is a part of DATE the user’s organization or an agent (such as a CRO), the clock should start when the sender learned of the cases.
Action 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.
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. 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.
15-8 Oracle Adverse Event Reporting System Administrator’s Guide
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
Flag
Explanation
Action
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.
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.
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:
IMPORT_EVENTS_TO_ DRUGS
NORMALIZE_DRUGS
If “N”, the report is processed without checking the version number.
If “N” the data is included in the case comments only.
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 This directory must be defined in to place acknowledgment the util_file_dir parameter in the messages. 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 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
E2B Configuration 15-9
Import processing
Flag
Explanation
Action
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.
If “Y”, the import creates a reportability record to store the license number.
If “N”, the license number in the The E2B format includes a input is treated as a non-importable license number for each field and it is stored in the case drug. This field is the comments. license number that the drug was administered under. CREATE_REGISTRY_ SOURCE
This flag is reserved for a If ‘Y’ the import creates a Report_ possible enhancement. It Source record with a type of “R”, is not implemented in 4.5. for Registry. Use the sender fields to fill in the details of this Report The E2B specifications Source record. distinguish between the If “N” the import does not create a role of primary sources registry source record. 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.
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.
Pre-import user exit If 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,
15-10 Oracle Adverse Event Reporting System Administrator’s Guide
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 Mapping Oracle 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 Fields Many 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 Table E2B 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 Configuration 15-11
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. 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.:
Other Case References AERS 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: Tag
OTHER_SOURCE_TYPE
safetyreportid
E2B
companynumb
CO
duplicatenumb
DUP
authoritynumb
AUT
othernumb
OTH
patientspecialistrecordnumb
SPN
patienthospitalrecordnumb
HPN
localreportnumb
RCV
safetyreportversion
VER
patientgpmedicalrecordnumb
GPN
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 Frequency The 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
15-12 Oracle Adverse Event Reporting System Administrator’s Guide
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 Features Once 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
E2B Configuration 15-13
E2B Automation Features
simultaneously. If two such processes start they should not interfere with each other's work. Gateway down This 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 Processing The 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
15-14 Oracle Adverse Event Reporting System Administrator’s Guide
E2B Automation Features
E2B_LOG Column
Tag or Notes
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.
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_Import The 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.
E2B Configuration 15-15
E2B Automation Features
E2B_LOG The E2B_LOG table logs automated import and export actions at a file level.
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 C = Completed A=Aborted. fail Processing was stopped programmatically without completing. F=Failed Processing was stopped because of an Oracle exception.
ERROR_CODE
The oracle error number
ERROR_MESSAGE
Error message
MESSAGE_TYPE
The type of message such as E2B or acknowlegementacknowl edgement
Usually null if the operation completed normally, e.g. ORA-20001
The value associated with the messagetype tag of the file being processed. ICHICSR ICHICSRACK
MESSAGE_NUMBER
The E2B message number.
NUMBER_OF_ REPORTS
The number of safety reports in the message.
The value associated with the messagenumb tag of the file being processed
Error handling The 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.
15-16 Oracle Adverse Event Reporting System Administrator’s Guide
E2B Automation Features
■
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 Automation The 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 directories E2B 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 permissions The 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('', 'SYS:java.io.FilePermission', '<E2B directory>', 'read'); SQL> exec dbms_java.grant_permission('', 'SYS:java.io.FilePermission','<E2B Directory>\*', 'delete');
Creating the database job The 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.
E2B Configuration 15-17
E2B Automation Features
15-18 Oracle Adverse Event Reporting System Administrator’s Guide
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 templates To 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. 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.
Note:
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.
Creating and managing document templates 16-1
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 template Once 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 <program name>.psp For example: loadpsp -replace -user aers1/aers1@aers45 AECaseSummaryListing.psp
Defining the template in the LETTERS table The 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.
16-2 Oracle Adverse Event Reporting System Administrator’s Guide
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 reports Oracle 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 Server To 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.
Managing programs and reports 17-1
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 AERS Most 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. Report maintenance is performed in the local Oracle AERS application.
Note:
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.
3.
Key in all fields.
4.
Do either of the following:
17-2 Oracle Adverse Event Reporting System Administrator’s Guide
Defining report parameters
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.
5.
Click the Save button. Oracle AERS saves the Report and Report Parameters to the database.
Defining report parameters All 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: 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.
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.
Managing programs and reports 17-3
Deleting reports
■
3.
# 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).
Click the Save button. Oracle AERS saves the report parameter to the database.
Deleting reports You can remove reports from the Oracle Report Server or in Oracle AERS.
Removing reports From the Portal Reports Security Registry To 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 AERS Before 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.
4.
Click the Delete button. The report disappears from the screen.
5.
Click the Save button. You do not receive a prompt. Oracle AERS deletes the report from the database.
Configuring Oracle AERS reports While external authorities largely dictate the format of each regulatory report, there is considerable variation in the approaches taken by companies in populating the report
17-4 Oracle Adverse Event Reporting System Administrator’s Guide
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 reports Oracle 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 values The 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
Managing programs and reports 17-5
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 parameters Program (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) Note:
The column must have the alias COL1 defined.
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-validation These 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. 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)
17-6 Oracle Adverse Event Reporting System Administrator’s Guide
Configuring report parameter cross-validation
Table 17–1 (Cont.) Descriptions of validation functions Validation Functions
Description
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
There is also a helper procedure in the RPCK package that is useful when you write your own report parameter validation function. Table 17–2
Helper procedure for report parameter validation
Validation Functions
Description
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.
Examples 1. 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.
Managing programs and reports 17-7
Customizable views used by reports
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.
Note:
Client extensions When 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 reports For more detailed information on the customizable views used by reports, see the Oracle AERS Reports Technical Reference Manual (TRM).
17-8 Oracle Adverse Event Reporting System Administrator’s Guide
Adding the company logo for MedWatch report
Configuring ad hoc reporting tools Clients 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 report The 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.
Managing programs and reports 17-9
Adding the company logo for MedWatch report
17-10 Oracle Adverse Event Reporting System Administrator’s Guide
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 configuration Oracle 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
Submission management
18-1
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 Wizard This 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.
18-2 Oracle Adverse Event Reporting System Administrator’s Guide
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 Rules Oracle 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 Syntax Oracle 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. Submission management
18-3
Maintaining Reportability Rules
■
■
■
■
■
■
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 criteria The 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.
4.
Click the Save button, or select File=>Save, to save your changes.
18-4 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining Reportability Rules
Creating or modifying a Reportability Rule Template Oracle 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). 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:
6.
Click the Save button, or select File=>Save, to save your changes.
Applying a Reportability Rule Template You 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.
6.
Click the Save button, or select File=>Save, to save your changes. When you Apply a template, all existing reportability rules for the matching Agency/License are over-written. You cannot undo the action.
Note:
Submission management
18-5
Maintaining Agency Reports
Managing individual reportability for an Approval The 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. 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:
7.
Click the Save button, or select File=>Save, to save your changes. and close the window.
Maintaining Agency Reports An 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). You can perform agency maintenance using the Oracle AERS Global Maintenance subsystem.
Note:
18-6 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining Agency Reports
Adding Agencies/Reports To 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.
4.
Click the Save button, or select File=>Save, to save your changes. The Agency is saved to the database.
Updating and deleting Agencies and Reports To 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.
5.
Click the Save button, or select File=>Save, to save your changes. 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.
3.
Click the Save button, or select File=>Save, to save your changes. 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.
Submission management
18-7
Maintaining Agency Reports
Field
Data Type
Notes
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.
18-8 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining Agency Reports
Field
Data Type
Notes
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_ Character SUBMISSIONS_PROC
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.
Submission management
18-9
Maintaining Agency Reports
18-10 Oracle Adverse Event Reporting System Administrator’s Guide
19 Oracle 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 Functionality The 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 Columns A 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 Oracle AERS dictionary architecture
19-1
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 TMS AERS 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 Functions The following list describes the AERS functions: ■
Case term classification
■
High Level Term Reporting
■
Dictionary Queries
■
Derived Unexpectedness
■
Omissions
AERS Dictionary API Definition This 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. Oracle does not guarantee that the API will not change in future releases of AERS.
Note:
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
19-2 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
■
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 Model A 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.
Definitions TID: 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 Domains AERS 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 Function Purpose: 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. Oracle AERS dictionary architecture
19-3
AERS Dictionary API Definition
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 Function Purpose: 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_DOMAINS This view is used by AERS to display a pick list of available domains. AERS selects distinct domain_id, name. 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.
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.
19-4 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
The following table shows the triggering action and the API function that is called. 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
E2B import The 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 Function Purpose: 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. Note:
This logic will not work with the new WHO Drug schema.
Then call TMS_USER_FULLAUTOCOADE. ClassifyTerm. Finally, compare the list of Active substances with the list in V_INGREDIENTS. Parameters:
Oracle AERS dictionary architecture
19-5
AERS Dictionary API Definition
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.
Return Value: 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.
Batch Reclassify Batch 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 Procedure BatchReclassify 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.
19-6 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
Specification: procedure BatchReclassify (pqid process_queue.queue_id%type, preasoncode varchar2, pOnlyDictionaryChanges varchar2, pAllCases varchar2, pCasesClassified OUT pls_integer, pTermsClassified OUT pls_integer); Parameter: Name
Values and Purpose
pqid
The QID of the report
preasoncode
A reason code is required when the case is locked.
pOnlyDictionaryChange s
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.
Reporting and High Level Term Derivation The 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.
Oracle AERS dictionary architecture
19-7
AERS Dictionary API Definition
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. 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.
V_ACTIVE_SUBSTANCES This 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. 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_ Varchar2 TYPE Substance_Name
This field is in the view because of its potential to support drug device combo products.
Varchar2
V_SPEC_CAT You 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. 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.
SPECIAL_CATEGORY Varchar2 SPECIAL_ CATEGORY_CODE
Number
AERS Dictionary Query An 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
19-8 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
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 Function When 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
Oracle AERS dictionary architecture
19-9
AERS Dictionary API Definition
AERS Parameter
Notes
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.
Dictionary Search Dialog Box For 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 Unexpectedness In 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.
19-10 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
Dictionary Content Views There 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_TERMS This 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. Column Name
Data Type
Purpose
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
V_PRODUCT_NAMES This view returns a list of all product names in the drug dictionary that are valid for data entry. 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.
Oracle AERS dictionary architecture 19-11
AERS TMS Interface Module
V_REGULATORY_GROUP_NAMES This view returns a list of all regulatory group names in the dictionary. It is used to validate the COMPANY_DRUGS table. Column Name
Data Type
Notes
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.
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. Module
Path
Dictionary Creation and Load Scripts
aers\database\configuraation\tms
19-12 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
Module
Path
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.
AERS Standard Dictionaries in TMS AERS 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 Drug The 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 Name The 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 Oracle AERS dictionary architecture 19-13
AERS TMS Interface Module
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 Name The 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 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.
The AERS WHO Drug implementation makes use of the TMS values associated with each term. The Who Drug data load populates these values.
19-14 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
AERS Enhancements to MedDRA AERS 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 modes There 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 Mode Classic 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 Mode Clinical 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 Example A 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 Mapping The 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.
Oracle AERS dictionary architecture 19-15
AERS TMS Interface Module
AERS
TMS
Notes
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.
Interface Module Tables This section defines tables that are used to map AERS data to TMS data. They are only used by API code.
AERS_TMS_DICTIONARY_COLUMNS Table When 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. Column Name
Data Type
Notes
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.
AERS_ DICTIONARY_ COLUMN_ID
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.
19-16 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
Column Name
Data Type
Notes
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.
AERS_TMS_TERM_ROWS The 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.
Column Name
Data Type
Usage
AERS_ DICTIONARY_ COLUMN_ID
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.
AERS Controls Table Entries The TMS interface makes use of the AERS CONTROLS table. The following tables lists the control ids used in the TMS interface. 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.
Oracle AERS dictionary architecture 19-17
AERS TMS Interface Module
Notes on AERS_Dictionary_API Package This 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.
GetLastOmissionKey ClassifyTerm 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. 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.
ReclassifyCase This 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.
Search The 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. 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
19-18 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
TMS Parameter Name
Derivation
pLanguage
pUDparam1
pApproved
pUDparam2
pScope
pUDparam3
pInconsFlag
pUDparam4
pRecordLimitn
pUDparam5
pStartLevelId
pStartlevel
pReverseAtLevelID
pHighestLevel
V View Implementation The 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 Form The 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 Box The 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 Views From 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 Install The 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.
Oracle AERS dictionary architecture 19-19
AERS TMS Interface Module
TMS Configuration and Dictionary Loading The 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 Install The 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 Labels The 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 Versions The 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.
19-20 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
Label Maintenance Form The 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.
Oracle AERS dictionary architecture 19-21
AERS TMS Interface Module
19-22 Oracle Adverse Event Reporting System Administrator’s Guide
20 Architectural details This chapter describes three features of the Oracle AERS architecture: ■
Audit trail
■
Data model naming conventions
Audit trail Case-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 conventions The following prefixes apply to case-related data within the data model. No Prefix Control, configuration and list tables.
Architectural details 20-1
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.
20-2 Oracle Adverse Event Reporting System Administrator’s Guide
A Oracle 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 Clinical Oracle 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 group 1.
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.
Oracle Clinical configuration A-1
Setting up value lookups from Oracle Clinical
It is not important which field is displayed on the Field Attributes form, because Record Groups are not directly related to fields.
Note:
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.
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:
7.
Commit.
Step 2: Assign record groups to fields 1.
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.
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.
Note:
Step 3: Define the LOV columns Click 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
A-2 Oracle Adverse Event Reporting System Administrator’s Guide
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 lookups This 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_STUDIES This section describes the definition and field LOV mappings for record group OCL_ STUDIES.
Record group definition 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'
Field LOV Mappings The following tables contain the field LOV mappings for the OCL_STUDIES record group. Each table title lists the form, window, and item. Table A–1
E_ENTRY, Demographics, STUDY_ID
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID
2
Description
600
Table A–2
E_ENTRY, Case Login, STUDY_ID_M0
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID
Oracle Clinical configuration A-3
Specific Oracle lookups
Table A–2 (Cont.) E_ENTRY, Case Login, STUDY_ID_M0 Column
Title
Width
Return Item
2
Description
60
Table A–3
Q_QUERY, Demographics, STUDY_ID_M0
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID_M0
2
Description
600
Table A–4
Q_QUERY, Case Login, STUDY_ID_M1
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID_M1
2
Description
600
Table A–5
Q_QUERY, Quick Query, STUDY_ID_M2
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID_M2
2
Description
600
Record group for centers: OCL_SITES This section describes the definition and field LOV mappings for record group OCL_ SITES.
Record group definition
Codelist
LOV name
Codelist executable text
OCL_SITES
COMMON_3_COLUMN_LOV SELECT B.STUDY_SITE COL1,
FROM
C.CITY
COL2,
C.COUNTRY
COL3
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
Field LOV mappings The following tables contain the field LOV mappings for the OCL_SITES record group. Each table title lists the form, window, and item.
A-4 Oracle Adverse Event Reporting System Administrator’s Guide
Specific Oracle lookups
Table A–6
E_ENTRY, Demographics, CENTER_ID
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID
2
City
300
3
Country
100
Table A–7
E_ENTRY, Case Login, CENTER _ID_M0
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M0
2
City
300
3
Country
100
Table A–8
Q_QUERY, Demographics, CENTER_ID
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID
2
City
300
3
Country
100
Table A–9
Q_QUERY, Case Login, CENTER _ID_M2
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M
2
City
300
3
Country
100
Table A–10
Q_QUERY, Quick Query, CENTER _ID_M1
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M1
2
City
300
3
Country
100
Record group for Investigators: OCL_INVESTIGATORS This section describes the definition and field LOV mappings for record group OCL_ INVESTIGATORS.
Oracle Clinical configuration A-5
Specific Oracle lookups
Record group definition Codelist
LOV Name
Codelist Executable Text
OCL_ INVESTIGATO RS
COMMON_5_COLUMN_LOV SELECT C.INVESTIGATOR COL1,
FROM
C.LAST_NAME
COL2,
C.FIRST_NAME
COL3,
C.CITY
COL4,
C.COUNTRY
COL5
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 A.CLINICAL_STUDY_ID = B.CLINICAL_ STUDY_ID AND
B.INVESTIGATOR_ID = C.INVESTIGATOR_ID
Field LOV Mappings The following tables contain the field LOV mappings for the OCL_INVESTIGATORS record group. Each table title lists the form, window, and item. Table A–11
E_ENTRY, Demographics, INVEST_ID
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID
2
Last Name
200
3
First name
200
4
City
300
5
Country
100
Table A–12
E_ENTRY, Case Login, INVEST_ID_M0
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID
2
Last Name
200
3
First name
200
4
City
300
5
Country
100
Table A–13
Q_QUERY, Demographics, INVEST_ID
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID_M0
2
Last Name
200
A-6 Oracle Adverse Event Reporting System Administrator’s Guide
Specific Oracle lookups
Table A–13 (Cont.) Q_QUERY, Demographics, INVEST_ID Column
Title
Width
Return Item
3
First name
200
4
City
300
5
Country
100
Table A–14
Q_QUERY, Case Login, INVEST_ID_M2
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID_M2
2
Last Name
200
3
First name
200
4
City
300
5
Country
100
Table A–15
Q_QUERY, Quick Query, INVEST_ID_M1
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID_M1
2
Last Name
200
3
First name
200
4
City
300
5
Country
100
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.
Oracle Clinical configuration A-7
Specific Oracle lookups
Record group definition 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, ' COL3,
DD-MON-YYYY') A.REPORTED_SEX
FROM
COL4
PATIENT_POSITIONS@ORACLIN
A,
CLINICAL_STUDY_VERSIONS@ORACLIN
B,
STUDY_SITE_PATIENT_POSITIONS@ORACLIN C, STUDY_SITES@ORACLIN WHERE B.STUDY =
D
: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_ID = B.CLINICAL_STUDY_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
Field LOV Mappings The following tables contain the field LOV mappings for the OCL_PATIENTS record group. Each table title lists the form, window, and item. Table A–16
E_ENTRY, Demographics, PATIENT_ID
Column
Title
Width
Return Item
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
Column
Title
Width
Return Item
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
A-8 Oracle Adverse Event Reporting System Administrator’s Guide
Oracle Clinical reconciliation views
Table A–18
Q_QUERY, Demographics, CENTER_ID
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID
2
City
300
3
Country
100
Table A–19
Q_QUERY, Case Login, CENTER _ID_M2
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M
2
City
300
3
Country
100
Table A–20
Q_QUERY, Quick Query, CENTER _ID_M1
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M1
2
City
300
3
Country
100
Oracle Clinical reconciliation views Oracle 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.
Oracle Clinical configuration A-9
Oracle Clinical reconciliation views
A-10 Oracle Adverse Event Reporting System Administrator’s Guide
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..................................................................................................................................... xiii Documentation Accessibility ................................................................................................................... xiv New in Oracle AERS 4.5.2 ....................................................................................................................... xiv Structure ..................................................................................................................................................... xv Related Documents .................................................................................................................................. xvii Conventions ............................................................................................................................................. xviii Checking MetaLink ................................................................................................................................. xviii
1
Oracle AERS overview Lock Manager............................................................................................................................................ Oracle AERS interface ............................................................................................................................. Navigator panel.................................................................................................................................. Console ................................................................................................................................................ Message line........................................................................................................................................ Status line ............................................................................................................................................ Toolbars .............................................................................................................................................. Oracle AERS features .............................................................................................................................. Basic querying (search) techniques ................................................................................................. Querying with wild cards ................................................................................................................. Function keys ...................................................................................................................................... Shortcut keys (key commands) ........................................................................................................ Closing/exiting before saving your work ......................................................................................
2
1-1 1-1 1-1 1-1 1-1 1-2 1-2 1-2 1-2 1-2 1-3 1-4 1-4
Administration overview Company product repository ................................................................................................................. Users and user group permissions........................................................................................................ Workflow tasks/data entry...................................................................................................................... Data management..................................................................................................................................... Reports........................................................................................................................................................ Query .......................................................................................................................................................... Dictionaries ............................................................................................................................................... Controls ......................................................................................................................................................
2-1 2-1 2-2 2-2 2-3 2-3 2-3 2-3
iii
3
Controls Discussion of the Controls table ........................................................................................................... 3-1 Listing and descriptions of AERS Controls ........................................................................................ 3-1
4
AERS Portal Portal components.................................................................................................................................... Implementing AERS Portal .................................................................................................................... AERS Portal Users and User Groups .............................................................................................. Modifying the AERS Home Page .................................................................................................... Modifying the Home Page attributes....................................................................................... Modifying the Pharma Solutions section ................................................................................ The Administration section ....................................................................................................... Modifying AERS Folders ........................................................................................................... AERS Documents custom items ............................................................................................... AERS Reports .............................................................................................................................. Modifying the AERS Portal Applications....................................................................................... AERS External Applications/Single Sign-on ...................................................................................... AERS 4.5.2 ........................................................................................................................................... AERS 4.5.2 Global Maintenance....................................................................................................... AERS 4.5.2 Workflow Configuration ..............................................................................................
4-2 4-3 4-3 4-3 4-3 4-4 4-4 4-4 4-5 4-6 4-6 4-6 4-6 4-7 4-7
5 Managing company product information Product Codes ........................................................................................................................................... 5-1 Adding Product Codes...................................................................................................................... 5-1 Updating Product Codes................................................................................................................... 5-2 Deleting Product Codes .................................................................................................................... 5-3 Company Products ................................................................................................................................... 5-3 Product details .................................................................................................................................... 5-3 Adding a Company Product ..................................................................................................... 5-3 Updating Company Products ................................................................................................... 5-4 Deleting Company Products ..................................................................................................... 5-5 Approvals ............................................................................................................................................ 5-5 Adding an approval ................................................................................................................... 5-5 Updating an approval ................................................................................................................ 5-6 Deleting approvals...................................................................................................................... 5-6 Labeling ............................................................................................................................................... 5-7 Adding Drug Labeling ............................................................................................................... 5-7 Deleting drug labeling associated with company drugs ...................................................... 5-7 Lots ....................................................................................................................................................... 5-8 Adding Lot details ...................................................................................................................... 5-8 Updating Lot details ................................................................................................................... 5-9 Deleting Lot details.................................................................................................................. 5-10 Exposure ........................................................................................................................................... 5-10 Updating Exposure details ..................................................................................................... 5-10 Updating Exposure details ..................................................................................................... 5-11 Deleting Exposure details ....................................................................................................... 5-11
iv
Contacts ............................................................................................................................................ Updating contacts .................................................................................................................... Deleting a contact..................................................................................................................... Packaging ......................................................................................................................................... Adding packaging details....................................................................................................... Deleting packaging details ..................................................................................................... Product Labels........................................................................................................................................ Creating a New Label ..................................................................................................................... Creating a New Version of a Label............................................................................................... Viewing Label Versions .......................................................................................................... Adding Event Terms ............................................................................................................... Label Qualifications ................................................................................................................. Activating a Label ........................................................................................................................... Copying an Existing Label.............................................................................................................
6
Maintaining the AERS-TMS Dictionary Conceptual Overview .............................................................................................................................. AERS-TMS MedDRA Implementation ........................................................................................... AERS-TMS WHO Drug Implementation ....................................................................................... Adding Company Products .................................................................................................................... Adding products to the AERS-TMS dictionary ............................................................................ Activating your newly added dictionary terms ............................................................................ Using TMS Domains ............................................................................................................................... Creating and using TMS Search Objects............................................................................................. Running Batch Reclassify.......................................................................................................................
7
5-12 5-12 5-12 5-13 5-13 5-13 5-14 5-14 5-15 5-15 5-15 5-15 5-16 5-17
6-1 6-1 6-1 6-2 6-3 6-7 6-7 6-8 6-8
Studies Maintaining Study Attributes ............................................................................................................... Study Security..................................................................................................................................... Study Products ................................................................................................................................... Adding Studies ......................................................................................................................................... Updating Studies...................................................................................................................................... Deleting Studies .......................................................................................................................................
7-1 7-2 7-2 7-2 7-2 7-2
8 Product Groups Defining Product Groups ....................................................................................................................... Adding Product Groups.......................................................................................................................... Updating Product Groups....................................................................................................................... Deleting Product Groups........................................................................................................................
9
8-1 8-1 8-2 8-2
Configuring AERS for multilingual use Overview of multilingual architecture ................................................................................................ Maintaining AERS Local Languages.................................................................................................... Setting a User’s Local Language............................................................................................................ Maintaining Codelist Translations .......................................................................................................
9-1 9-1 9-2 9-2
v
Maintaining Field and Window Label Translations ......................................................................... Adding Field Label Translations ..................................................................................................... Adding Window Label Translations ............................................................................................... Maintaining Error Messages and Translations................................................................................... Adding Error Message Translations ...............................................................................................
10
Supporting your work processes Case statuses........................................................................................................................................... Action items............................................................................................................................................ Document templates ............................................................................................................................. Creating the template PL/SQL .................................................................................................... Loading the template...................................................................................................................... Defining the template in the LETTERS table .............................................................................. Workflow tasks ...................................................................................................................................... Defining Workflow tasks ............................................................................................................... Assigning Workflow tasks to users .............................................................................................. Designing screens ................................................................................................................................. Global screens and fields configuration....................................................................................... FIELD_ATTRIBUTES Table Description .............................................................................. WDW_ATTRIBUTES Table Description ............................................................................ Modifying the global screens and fields configuration attributes ......................................... Revealing custom fields ............................................................................................................... Workflow-specific screens and fields configuration................................................................ FIELD_MODES Table............................................................................................................ WINDOW_MODES Table .................................................................................................... Modifying Workflow-specific screen and field configuration ............................................... Configuring the data entry Navigator panel.................................................................................. Creating the Code List entry ....................................................................................................... Creating Record Groups .............................................................................................................. Creating the SQL statement to display the Navigator view ................................................... Configuration consistency constraints............................................................................................
11
10-1 10-3 10-3 10-3 10-4 10-4 10-5 10-6 10-8 10-8 10-9 10-9 10-11 10-12 10-12 10-13 10-13 10-13 10-14 10-14 10-15 10-15 10-16 10-17
Managing Users And User Groups Overview of Oracle AERS user security ........................................................................................... Security objects ................................................................................................................................ User groups............................................................................................................................... Users .......................................................................................................................................... Types of Oracle AERS security ..................................................................................................... Case ownership ........................................................................................................................ Case permissions...................................................................................................................... Oracle Roles .............................................................................................................................. Portal Roles/Groups ............................................................................................................... Oracle AERS User Roles.......................................................................................................... Setting up Oracle AERS for users ...................................................................................................... Managing Oracle AERS Roles ............................................................................................................ Maintaining user groups...................................................................................................................... Understanding user group permissions ......................................................................................
vi
9-3 9-3 9-4 9-4 9-4
11-1 11-1 11-1 11-2 11-2 11-2 11-2 11-3 11-3 11-3 11-3 11-3 11-4 11-5
Adding permissions to a user group............................................................................................ Adding user groups........................................................................................................................ Updating user groups..................................................................................................................... Deleting user groups ...................................................................................................................... Maintaining users ................................................................................................................................. Creating AERS users....................................................................................................................... Assigning Oracle passwords ......................................................................................................... Assigning roles ................................................................................................................................ Baseline Oracle Roles............................................................................................................... Optional AERS Roles............................................................................................................... Other AERS Application Roles ............................................................................................ Portal Groups (Roles) ............................................................................................................ Assigning roles to a user ....................................................................................................... Updating user attributes and permissions ................................................................................ User permissions.................................................................................................................... Local privacy and security ................................................................................................................. Configuration Components ......................................................................................................... Example 1: Local Privacy configuration for patient name and address ............................... Example 2: Local Security configuration for assessment data ............................................... Configuration Procedure ............................................................................................................. Record-level filtering.......................................................................................................................... Configuration components .......................................................................................................... Example 1: Reportability/Submission History filtering for local affiliate............................ Example 2: Investigation filtering for Product Complaint investigation users ................... Configuration Procedure ............................................................................................................. Managing passwords.......................................................................................................................... Configuring passwords................................................................................................................ Unlocking Single Sign-On (SSO)................................................................................................. Configuring application-level timeout ...................................................................................... Resetting a user’s password ........................................................................................................ Changing the PORTAL30 Password ..........................................................................................
11-5 11-5 11-6 11-6 11-7 11-7 11-8 11-8 11-8 11-9 11-10 11-11 11-11 11-12 11-13 11-14 11-14 11-15 11-15 11-16 11-16 11-17 11-17 11-18 11-18 11-21 11-21 11-21 11-22 11-22 11-23
12 Data management Change reason codes............................................................................................................................. TE_CASE_VERSION/TH_CASE_VERSION view .................................................................... Duplicate checking ............................................................................................................................... Duplicate check API........................................................................................................................ Description................................................................................................................................ Input parameters...................................................................................................................... Output ....................................................................................................................................... Duplicate Check logic..................................................................................................................... Clinical AE Cases ..................................................................................................................... Non-Clinical AE Cases (Spontaneous, Registry, Literature, etc.) ..................................... Product Complaint Cases ....................................................................................................... Copy Case ............................................................................................................................................... Generic implementation................................................................................................................. Data derivation procedures .................................................................................................................
12-1 12-1 12-2 12-2 12-2 12-2 12-3 12-3 12-4 12-4 12-5 12-5 12-5 12-8
vii
Case ID generation.......................................................................................................................... Updating the Case ID generation algorithm........................................................................ Case data derivations ..................................................................................................................... Field/Record/Record block, DB derivations ...................................................................... Updating and compiling the derivation library .................................................................. Generating the library ........................................................................................................... Standard derivation procedures .......................................................................................... Field code lists...................................................................................................................................... Adding new code lists .................................................................................................................. Step 1: Create the new code list ........................................................................................... Step 2: Add individual code list items ................................................................................ Step 3: Create a Record Group ............................................................................................. Step 4: Assigning code lists to fields ................................................................................... Creating SQL lookup code lists................................................................................................... Updating existing code lists ........................................................................................................ Updating an item in a code list ............................................................................................ Retiring code list values ........................................................................................................ Reactivating retired individual code list items.................................................................. Deleting code lists ......................................................................................................................... Deleting individual code list items............................................................................................. Edit checks ............................................................................................................................................ Updating the edit check program............................................................................................... Table descriptions ......................................................................................................................... RULE_ATTRIBUTES table.................................................................................................... RULE_FIRING_MODES table..............................................................................................
12-8 12-9 12-9 12-9 12-9 12-10 12-11 12-13 12-14 12-14 12-14 12-15 12-15 12-16 12-17 12-17 12-18 12-18 12-18 12-19 12-19 12-20 12-20 12-21 12-21
Edit check example 22 Spell Check........................................................................................................................................... Configuring for Microsoft Word................................................................................................. Installing JSpell in Oracle AERS ................................................................................................. Reconciliation ...................................................................................................................................... Modifying Reconciliation............................................................................................................. Staging tables ................................................................................................................................. RCN_CASES table ................................................................................................................. RCN_PATIENT table ............................................................................................................ RCN_PATIENT_VITALS table ............................................................................................ RCN_PT_AE_PROFILE table ............................................................................................... RCN_PT_CAUSE_DEATH table ......................................................................................... RCN_PT_DOSING table ....................................................................................................... Clinical data extract file ..................................................................................................................... Coded field translations ............................................................................................................... Clinical extract load program......................................................................................................
12-22 12-23 12-23 12-24 12-24 12-26 12-26 12-27 12-27 12-28 12-29 12-29 12-30 12-31 12-31
13 Configuring Case Browse Overview................................................................................................................................................. Modes................................................................................................................................................ Field Attributes................................................................................................................................ Relevant Field Modes .....................................................................................................................
viii
13-1 13-1 13-1 13-2
Adding or Updating a Custom Browse Configuration .................................................................. 13-3 Fields Available for Configuration .................................................................................................... 13-4 Out-of-the-Box Case Browse Configuration .................................................................................... 13-6
14
Case Data Query Query configuration ............................................................................................................................. Modifying existing query configuration...................................................................................... Adding new query fields ............................................................................................................... Creating support views........................................................................................................... Adding the Query Table Join ................................................................................................. Adding a new field to the query screens.............................................................................. Adding an Exclude Flag to a new block ............................................................................... Adding custom queries ........................................................................................................................
15
E2B Configuration Run-Time Parameters ........................................................................................................................... Export processing .................................................................................................................................. Configuring E2B Export (submissions)........................................................................................ E2B_RECEVIERS Table .................................................................................................................. Import processing.................................................................................................................................. Import Rules .................................................................................................................................... E2B Data Mapping .............................................................................................................................. E2B Automation Features .................................................................................................................. Supported Automation Features ................................................................................................ Gateway Event and MDN Processing........................................................................................ Batch_Import ................................................................................................................................. Error handling ............................................................................................................................... Configuring Automation .............................................................................................................
16
15-1 15-2 15-2 15-2 15-6 15-7 15-11 15-13 15-13 15-14 15-15 15-16 15-17
Creating and managing document templates Document templates ............................................................................................................................. Creating the template PL/SQL .................................................................................................... Loading the template...................................................................................................................... Defining the template in the LETTERS table ..............................................................................
17
14-1 14-1 14-4 14-4 14-5 14-5 14-6 14-6
16-1 16-1 16-2 16-2
Managing programs and reports Installing new reports .......................................................................................................................... Registering new reports on the Oracle Report Security Server................................................ Installing new reports on Oracle AERS ....................................................................................... Defining report parameters................................................................................................................. Deleting reports ..................................................................................................................................... Removing reports From the Portal Reports Security Registry ................................................. Deleting reports on Oracle AERS ................................................................................................. Configuring Oracle AERS reports ..................................................................................................... Configuring code lists used by reports .............................................................................................
17-1 17-1 17-2 17-3 17-4 17-4 17-4 17-4 17-5
ix
Managing report decode values.................................................................................................... 17-5 Configuring default values for program parameters ..................................................................... 17-6 Configuring report parameter cross-validation............................................................................... 17-6
Client extensions example 8 Customizable views used by reports................................................................................................. 17-8 Configuring ad hoc reporting tools .............................................................................................. 17-9 Adding the company logo for MedWatch report ............................................................................ 17-9
18
Submission management Overview of Submission Tracking functions and supporting configuration ........................... Running the Submission Wizard .................................................................................................. Maintaining Reportability Rules ....................................................................................................... Reportability Rule Syntax .............................................................................................................. Setting the case data level of reportability criteria ..................................................................... Creating or modifying a Reportability Rule Template.............................................................. Applying a Reportability Rule Template..................................................................................... Managing individual reportability for an Approval ................................................................. Maintaining Agency Reports .............................................................................................................. Adding Agencies/Reports............................................................................................................. Updating and deleting Agencies and Reports............................................................................ AGENCY_REPORTS table definition ..........................................................................................
18-1 18-2 18-3 18-3 18-4 18-5 18-5 18-6 18-6 18-7 18-7 18-7
19 Oracle AERS dictionary architecture Overview of AERS Dictionary Functionality .................................................................................. Dictionary Columns........................................................................................................................ AERS, Dictionary Management, and TMS .................................................................................. AERS Dictionary Related Functions............................................................................................. AERS Dictionary API Definition ....................................................................................................... Dictionary Interface Data Model .................................................................................................. Definitions................................................................................................................................. Dictionary Version Support and Domains .................................................................................. SetDomain Function ................................................................................................................ GetCurrentDomainFunction Function.................................................................................. V_DICT_DOMAINS ................................................................................................................ Classification.................................................................................................................................... Batch Reclassify ........................................................................................................................ Reporting and High Level Term Derivation ............................................................................... V_ACTIVE_SUBSTANCES .................................................................................................... V_SPEC_CAT ........................................................................................................................... AERS Dictionary Query ................................................................................................................. Dictionary Pipeline Function ................................................................................................. Dictionary Search Dialog Box .............................................................................................. Derived Unexpectedness ............................................................................................................. Dictionary Content Views............................................................................................................ V_MEDDRA_TERMS ............................................................................................................ V_PRODUCT_NAMES ........................................................................................................ V_REGULATORY_GROUP_NAMES................................................................................. x
19-1 19-1 19-2 19-2 19-2 19-3 19-3 19-3 19-3 19-4 19-4 19-4 19-6 19-7 19-8 19-8 19-8 19-9 19-10 19-10 19-11 19-11 19-11 19-12
AERS TMS Interface Module .......................................................................................................... AERS Standard Dictionaries in TMS .......................................................................................... AERS enhancements to WHO Drug ................................................................................... AERS Enhancements to MedDRA....................................................................................... Reporting view modes ................................................................................................................. Classic Mode........................................................................................................................... Clinical Compatibility Mode................................................................................................ AERS/TMS Concept Mapping.................................................................................................... Interface Module Tables............................................................................................................... AERS_TMS_DICTIONARY_COLUMNS Table ................................................................ AERS_TMS_TERM_ROWS................................................................................................... AERS Controls Table Entries................................................................................................ Notes on AERS_Dictionary_API Package ................................................................................. GetCurrentDomainFunction ................................................................................................ GetLastOmissionKey............................................................................................................. ReclassifyCase ........................................................................................................................ Search....................................................................................................................................... V View Implementation ............................................................................................................... Forms Implementation ................................................................................................................. Drill Down Views.......................................................................................................................... TMS integration Install................................................................................................................. TMS Configuration and Dictionary Loading..................................................................... AERS Standard TMS API Install.......................................................................................... Derived Unexpectedness and Product Labels .......................................................................... Metadata and Label Versions............................................................................................... Label Maintenance Form ......................................................................................................
20
19-12 19-13 19-13 19-15 19-15 19-15 19-15 19-15 19-16 19-16 19-17 19-17 19-18 19-18 19-18 19-18 19-18 19-19 19-19 19-19 19-19 19-20 19-20 19-20 19-20 19-21
Architectural details Audit trail................................................................................................................................................ 20-1 Data model naming conventions ....................................................................................................... 20-1
A
Oracle Clinical configuration Setting up value lookups from Oracle Clinical................................................................................. Step 1: Define record group ............................................................................................................. Step 2: Assign record groups to fields............................................................................................ Step 3: Define the LOV columns ..................................................................................................... Specific Oracle lookups ......................................................................................................................... Record group for clinical studies: OCL_STUDIES ....................................................................... Record group definition............................................................................................................ Field LOV Mappings ................................................................................................................. Record group for centers: OCL_SITES........................................................................................... Record group definition............................................................................................................ Field LOV mappings ................................................................................................................. Record group for Investigators: OCL_INVESTIGATORS .......................................................... Record group definition............................................................................................................ Field LOV Mappings .................................................................................................................
A-1 A-1 A-2 A-2 A-3 A-3 A-3 A-3 A-4 A-4 A-4 A-5 A-6 A-6
xi
Record group for patient details: OCL_PATIENTS (multicolumn) .......................................... Record group definition............................................................................................................ Field LOV Mappings ................................................................................................................. Oracle Clinical reconciliation views....................................................................................................
xii
A-7 A-8 A-8 A-9
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 audience The 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 administrators Installing 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 administrators Maintaining 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 xiii
■
setting and using environment variables
Documentation Accessibility Our 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 Documentation Screen 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 Documentation This 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 Services Oracle 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 Unexpectedness AERS 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 Dates Some 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.
xiv
Enhance the AERS Product Label Repository The 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 10g The AERS technology stack is upgraded to 10G from Forms 6 and Reports 9iDS.
Structure This 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.
xv
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.
xvi
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 Documents This 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 Documentation The 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) Documentation The 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) Documentation The 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)
xvii
Oracle Clinical SiteMinder Documentation The Oracle Clinical SiteMinder documentation includes: ■
Oracle Clinical SiteMinder User Guide (B15643)
■
Oracle Clinical SiteMinder Installation Guide (B15645)
Oracle Clinical TrialMinder Documentation The 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)
Conventions The following text conventions are used in this document: 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.
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:
xviii
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.
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.
xix
xx
1 Oracle 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 Manager The 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 interface This 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 panel The 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.
Console The 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 line Two types of messages may be displayed on this line: ■
Oracle® Forms™ standard messages.
■
Application-specific messages Oracle AERS overview 1-1
Oracle AERS features
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 line The Status Line displays helpful information about particular fields or records in a block. 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
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 features This 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) techniques The 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 cards When 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 1-2 Oracle Adverse Event Reporting System Administrator’s Guide
Oracle AERS features
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: Operator
Description
Example
%
Wild card (one or more characters)
A%
_
Wild card (single character only)
A_pirin
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 keys Function 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. 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
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)
Oracle AERS overview 1-3
Oracle AERS features
Table 1–2 (Cont.) Function keys Key
Action
Ctrl + Z
Undo last editing
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 work If 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.
1-4 Oracle Adverse Event Reporting System Administrator’s Guide
2 Administration 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 repository The 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 permissions Users 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
Administration overview
2-1
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 entry A 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 management Oracle 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.
2-2 Oracle Adverse Event Reporting System Administrator’s Guide
Controls
Reports Oracle 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.
Query The 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.
Dictionaries Oracle 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".
Controls The Controls tables are present at each site. The tables contain a number of specific, site-wide parameters that control various features of the application.
Administration overview
2-3
Controls
2-4 Oracle Adverse Event Reporting System Administrator’s Guide
3 Controls 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 table The 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 Controls The 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.ht ml
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 Discoverer Viewer on hoc data visualization environment. 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.
Controls
3-1
Listing and descriptions of AERS Controls
Table 3–1 (Cont.) AERS Controls Table CONTROL_ID
CONTROL_VALUE
Default Value
AERS_LETTER_URL
The URL used to launch the letter generation page. This item is not configurable.
Portal To AERS. Show Letter? p_ lettername=LETTER NAME
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
YYYYS1 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).
CASE_CLOSED_ STATUS
Case Status for a closed case.
CLOSE_REASON_LIST
C 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
N 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.
ERROR_LOGGER_JOB
The job ID for the AERS Error Logger.
3-2 Oracle Adverse Event Reporting System Administrator’s Guide
(Set at installation)
Listing and descriptions of AERS Controls
Table 3–1 (Cont.) AERS Controls Table CONTROL_ID
CONTROL_VALUE
Default Value
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/b rowser/tms_user_ browser_ finddemo.openfram e?pdictid=72
FORCE_UPR_IN_QK_ OPEN
Values: Y/N. When set to ‘Y,’ the Case Y ID entered in the Quick Open dialog box is automatically converted to upper case.
GMT_TIME_OFFSET
Difference in time (±)(HH:MM) between 0:00 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).
HELP_URL_PREFIX
The location of the xHelp system.
http://forms_ server/opa45/xhel p
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 PATIENT_CONTEXT_ Extract Load. 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.selectite mtype…
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
Controls
3-3
Listing and descriptions of AERS Controls
Table 3–1 (Cont.) AERS Controls Table CONTROL_ID
CONTROL_VALUE
Default Value
PORTAL_PLS_URL
The URL for the Portal DAD.
http://forms server/pls/portal 30
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
DELETE 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.
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
e.g. jspell_ This specifies the HTTP server and port server.oracle.com:80 where JSpell servlet is installed,. If left blank, it implies the JSpell servlet is installed in the same server as the Forms server.
SUB_EXCLD_STATUS_ Setting specifying the case status of cases 0 1 to be excluded from submission reports; e.g., exclude all cases with status of 1 (Login). SUBWIZ_USE_ EVENT_TO_DRUG_ ASSESSMENT
When Y, the Submission Wizard uses the Y lowest level information available for determining reportability. When N, the case level flags are used.
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 TERM_REASON_LIST Extract Load.
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.
3-4 Oracle Adverse Event Reporting System Administrator’s Guide
151
Listing and descriptions of AERS Controls
Table 3–1 (Cont.) AERS Controls Table CONTROL_ID
CONTROL_VALUE
Default Value
TMS_XSYSTEM_KEY
The external system integration key used AERS1 by this instance of AERS to access TMS. Our standard is to use the AERS schema name.
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.
WARNING_TIMEOUT
The inactivity time in seconds, before the 1200 timeout warning screen displays.
US_REP_TYPE_LIST
Controls
3-5
Listing and descriptions of AERS Controls
3-6 Oracle Adverse Event Reporting System Administrator’s Guide
4 AERS 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 overview Oracle Portal has a three-tier architecture that scales to suit any sized company. The tier components are:
AERS Portal 4-1
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 components AERS 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 page A 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.
Portlet A 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 areas Content 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.
4-2 Oracle Adverse Event Reporting System Administrator’s Guide
Implementing AERS Portal
Applications An 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 Applications Oracle 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 Portal Oracle 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 Groups Each 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 Page The 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 attributes The 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).
AERS Portal 4-3
Implementing AERS Portal
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 section Pharma 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 section The 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 Folders The 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.
4-4 Oracle Adverse Event Reporting System Administrator’s Guide
Implementing AERS Portal
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 items Within 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 Portal 4-5
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 Reports The 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 Applications Oracle 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-on Oracle 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.2 The AERS 4.5.2 external application corresponds to the main AERS system (case management, query, reporting, etc.).
4-6 Oracle Adverse Event Reporting System Administrator’s Guide
AERS External Applications/Single Sign-on
AERS 4.5.2 Global Maintenance The 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 Configuration The 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.
AERS Portal 4-7
AERS External Applications/Single Sign-on
4-8 Oracle Adverse Event Reporting System Administrator’s Guide
5 Managing 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 Codes A 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). You can maintain Product Codes by using the Oracle AERS Global Maintenance subsystem.
Note:
Adding Product Codes A 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.
Managing company product information 5-1
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: ■
■ ■
■
5.
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).
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 Codes You 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. The Products Maintenance 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.
Key in changes to the Description field.
4.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the updated Description to the database.
5-2 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
Deleting Product Codes 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.
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.
4.
Click the Save button or press the F10 key to save changes. You do not receive a prompt. Oracle AERS deletes the Product Code from the database.
Company Products Oracle 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 details The 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. The Oracle AERS dictionary structure and interface are fully described in Chapter 19, "Oracle AERS dictionary architecture" of this guide. Note:
Adding a Company Product In 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 Managing company product information 5-3
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. We recommend creating the Product Code first. See Adding Product Codeson on page 5-1.
Note:
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.
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. ■
■
■
■
■
4.
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.
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 Products To update a product: 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.
Select a Product from the Navigator panel.
3.
Key in the appropriate changes.
4.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the changes.
5-4 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
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).
Deleting Company Products To delete a product: 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.
Select a Product from the Navigator panel.
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.
4.
Click the Save button, press the F10 key, or select File=>Save to save changes.
Approvals Oracle 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 approval To add a product approval: 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. Managing company product information 5-5
Company Products
2.
Select a Product from the Navigator panel.
3.
Select the Approvals tab. The Approval tab displays.
4.
Key in all fields. ■
Country: The Country or Agency providing the license/approval.
■
Type: The license type
■
License Number
■
License Date
■
■
■
■
■
5.
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.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the Approval to the database.
Updating an approval To update an approval: 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.
Select a Product from the Navigator panel.
3.
Select the Approvals tab. The Approval tab displays.
4.
Key in the appropriate changes.
5.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the changes to the database.
Deleting approvals To delete a Approval: 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.
Select a Product from the Navigator panel.
3.
Select the Approvals tab. The Approval tab displays.
5-6 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
4.
Highlight the Approval record to be removed 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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the Approval to the database.
Labeling Core 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 Labeling To add Drug Labeling: 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.
Select a Product from the Navigator panel.
3.
Select the Labeling tab. The Labeling tab displays.
4.
Key in all fields. ■
■
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.
■
■
5.
Core Label Name - Use the codelist to associate the core label with a product label.
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.
Press the Save button or F10 to save changes. Oracle AERS saves the Approval to the database.
Deleting drug labeling associated with company drugs To delete a Labeling: 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.
2.
Select a Product from the Navigator panel.
3.
Select the Labeling tab. The Labeling tab displays.
Managing company product information 5-7
Company Products
4.
Highlight the Labeling record to be removed 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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS deletes the Labeling from the database.
Lots Oracle 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 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.
Note:
To load Lot details directly into tables: 1.
Prepare a text file that matches the following load specifications:
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.
5-8 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
Column
Req? Type
Start
Stop
Description
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.
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. The Labeling tab displays.
4.
Run the LOAD_LOTS.CTL SQL*Loader file connected as the schema owner of Global Maintenance tables.
To add Lot details manually: 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.
Select a Product from the Navigator panel.
3.
Select the Lot tab. The Lot tab displays.
4.
5.
Key in all fields. ■
Label Lot
■
Fill Lot
■
Bulk Lot
■
Package Lot
■
Expiration Date
■
Distribution Date
■
Number of Doses
■
NDC
■
Manufacturer
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the Lot information to the database.
Updating Lot details To update Lot details: 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.
Managing company product information 5-9
Company Products
2.
Select a Product from the Navigator panel.
3.
Select the Lot tab. The Lot tab displays.
4.
Key in the appropriate changes.
5.
Press the Save button or F10 to save changes. Oracle AERS saves the changes to the database.
Deleting Lot details To delete Lot details: 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.
Select a Product from the Navigator panel.
3.
Select the Lot tab. The Lot tab displays.
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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Exposure Oracle 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 details You 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)
The Product Formulation. This field must match the Drug Form
Y
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
5-10 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
Column
Data Type
Req?
Description
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.
To add Exposure details manually: 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.
Select a Product from the Navigator panel.
3.
Select the Exposure tab. The Exposure tab displays.
4.
5.
Key in all fields. ■
Exposure Month
■
Exposure Measure
■
Indication
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the Lot information to the database.
Updating Exposure details To update Exposure details: 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.
Select a Product from the Navigator panel.
3.
Select the Exposure tab. The Exposure tab displays.
4.
Key in the appropriate changes.
5.
Press the Save button or F10 to save changes. Oracle AERS saves the changes to the database.
Deleting Exposure details To delete Exposure details: 1.
Select the Products tab from the Oracle AERS Global Maintenance subsystem.
Managing company product information 5-11
Company Products
The Products Maintenance screen displays with the list of Company Products visible in the Navigator panel. 2.
Select a Product from the Navigator panel.
3.
Select the Exposure tab. The Exposure tab displays.
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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Contacts A 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: 1.
Select a Product from the Navigator panel.
2.
Select the Contact tab. The Contact tab displays.
3.
Key in all fields.
4.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the Contact to the database.
Updating contacts To update contact information: 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.
Select a Product from the Navigator panel.
3.
Select the Contact tab. The Contact tab displays.
4.
Key in the appropriate changes.
5.
Press the Save button or F10 or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Deleting a contact To delete a Contact: 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.
5-12 Oracle Adverse Event Reporting System Administrator’s Guide
Company Products
2.
Select a Product from the Navigator panel.
3.
Select the Contact tab. The Contact tab displays.
4.
Highlight the Contact record to be removed 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.
5.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Packaging Oracle 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. 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.
Adding packaging details To add Packaging details: 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.
Select a Product from the Navigator panel.
3.
Select the Packaging tab. The Packaging tab displays.
4.
Enter the packaging details.
5.
Click the Save button. Oracle AERS saves the changes to the database.
Deleting packaging details To delete packaging details: 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.
Managing company product information 5-13
Product Labels
2.
Select a Product from the Navigator panel.
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. You do not receive a prompt. The Product Code is deleted from the database.
5.
Click the Save button or select File=>Save to save changes. Oracle AERS saves the changes to the database.
Product Labels The 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 Label New 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.
5-14 Oracle Adverse Event Reporting System Administrator’s Guide
Product Labels
Creating a New Version of a Label Once 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 Versions To 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 Terms To 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 Qualifications AERS 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.
Managing company product information 5-15
Product Labels
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
Activating a Label When 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:
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.
5-16 Oracle Adverse Event Reporting System Administrator’s Guide
Product Labels
Field / Button
Result
Apply to Selected Labels
Button. Clicking the Apply to Selected Labels button applies the date to the effective date to any selected labels.
3.
Select the Check radio button and click Run to run the TMS check mode. ■
4.
Select the Activate radio button and click Run to activate the label. ■
5.
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.
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.
Click Summary to return to the Product Labels screen, or click Exit to close the screen.
Copying an Existing Label You 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.
Managing company product information 5-17
Product Labels
5-18 Oracle Adverse Event Reporting System Administrator’s Guide
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.
Conceptual Overview Oracle 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 Implementation AERS 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 Implementation Oracle 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
Maintaining the AERS-TMS Dictionary 6-1
Adding Company Products
well as simplify the management of the AERS Company Product Repository (see "Company product repository" on page 2-1).
Regulatory Group Name The 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 Name The 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 Type The 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 Flag The 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 Products Each 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 6-2 Oracle Adverse Event Reporting System Administrator’s Guide
Adding Company Products
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. Maintaining the AERS-TMS Dictionary 6-3
Adding Company Products
Adding a New Regulatory Group Name You 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 Name You 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 Name If your company product already has a preferred name in WHO-DRUG, you can associate that existing name with your Regulatory Group Name. 6-4 Oracle Adverse Event Reporting System Administrator’s Guide
Adding Company Products
To assign an existing preferred name, to a 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.
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.
4.
Enter the AERS Product Type (DRUG, DEVICE, VACCINE) and Blinded Therapy Type (B for blinded therapy, P for placebo).
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: ■
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 Synonym in the Term field in the top block and press Tab. The Synonym details appear. Press Save again to store the relationship.
Maintaining the AERS-TMS Dictionary 6-5
Adding Company Products
Assigning an existing Synonym (Trade Name) to your Regulatory Group Name If 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 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.
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 Name The 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.
4.
Enter the AERS Product Type (DRUG, DEVICE, VACCINE) and Blinded Therapy Type (B for blinded therapy, P for placebo).
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: ■
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.
6-6 Oracle Adverse Event Reporting System Administrator’s Guide
Using TMS Domains
■
■
7.
Enter the Company Product Name in the Term field in the top block and press Tab. The Company Product Name details appear. Press Save again to store the relationship.
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 terms Once 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 Domains A 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 TMS To 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 Domain Once 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, Maintaining the AERS-TMS Dictionary 6-7
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 Objects A 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 Reclassify Batch 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
6-8 Oracle Adverse Event Reporting System Administrator’s Guide
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.
Maintaining the AERS-TMS Dictionary 6-9
Running Batch Reclassify
6-10 Oracle Adverse Event Reporting System Administrator’s Guide
7 Studies The section describes how to manage studies.
Maintaining Study Attributes The 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: 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.
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.
Studies
7-1
Adding Studies
Study Security You 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 Products On 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 Studies To 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.
4.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS adds the study to the database.
Updating Studies To update a study: 1.
Select the Study tab from the Oracle AERS Global Maintenance subsystem. The Study Maintenance screen displays.
2.
Select the study you want to update.
3.
Key in the appropriate changes.
4.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS saves the updates to the database.
Deleting Studies 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.
To delete a study: 7-2 Oracle Adverse Event Reporting System Administrator’s Guide
Deleting Studies
1.
Select the Study tab from the Oracle AERS Global Maintenance subsystem. The Study Maintenance screen displays.
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
4.
Click the Save button, press the F10 key, or select File=>Save to save changes. Oracle AERS deletes the study from the database.
Studies
7-3
Deleting Studies
7-4 Oracle Adverse Event Reporting System Administrator’s Guide
8 Product 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 Groups You 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. Note: Product Group maintenance is performed in the Global Maintenance subsystem.
Adding Product Groups To 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.
Product Groups 8-1
Updating Product Groups
5.
Press the Save button or F10 to save changes. 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.
8.
Click the Save button or press the F10 key to save changes. The new Product group with its associated Product Codes/Studies is saved to the database.
Updating Product Groups To update a Product Group: 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.
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.
4.
Click the Save button or press the F10 key to save changes. The new Product group with its associated Product Codes/Studies is saved to the database.
Deleting Product Groups 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.
To delete a Product Group, you must first delete the Product Codes associated with the group, then delete the group itself: 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.
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
8-2 Oracle Adverse Event Reporting System Administrator’s Guide
Deleting Product Groups
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.
5.
Click the Save button or press the F10 key to save changes. The Product Group is deleted from the database.
Product Groups 8-3
Deleting Product Groups
8-4 Oracle Adverse Event Reporting System Administrator’s Guide
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.
Overview of multilingual architecture Oracle 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.
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.’
Note:
Maintaining AERS Local Languages The 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.
Configuring AERS for multilingual use
9-1
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.
■
5.
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.
Save you changes.
Setting a User’s Local 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. 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 Translations Oracle 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.
9-2 Oracle Adverse Event Reporting System Administrator’s Guide
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.
6.
Save your changes.
Maintaining Field and Window Label Translations Field 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 Translations To 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.
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.
Note:
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.
Configuring AERS for multilingual use
9-3
Maintaining Error Messages and Translations
Adding Window Label Translations To 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.
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:
5.
Enter the local language translation for the Window Label. ■
Language Code: Enter the local language code as created above.
■
Window Label: Enter the local language translation of the screen label.
6.
Save your changes by pressing F10.
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 Translations Error messages can also be translated into your user’s local languages to assist in the usability of Oracle AERS.
Adding Error Message Translations To 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.
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.
Note:
4.
Enter the local language translation for the error message. ■
Language Code: Enter the local language code as created above.
■
Error Message: Enter the local language translation of the error message.
9-4 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining Error Messages and Translations
5.
Save your changes by pressing F10.
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.
Configuring AERS for multilingual use
9-5
Maintaining Error Messages and Translations
9-6 Oracle Adverse Event Reporting System Administrator’s Guide
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 statuses Oracle 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.
Supporting your work processes 10-1
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
■
■
4.
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.
Click the Save button or press the F10 key to save changes. 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
10-2 Oracle Adverse Event Reporting System Administrator’s Guide
Document templates
(’MEDICAL-REVIEW’, ’DE COMPLETE’, NULL, ’Y’); 3.
Commit your changes.
Action items Action 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 templates A 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. 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.
Note:
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.
Supporting your work processes 10-3
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 template Once 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
Defining the template in the LETTERS table The 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.
10-4 Oracle Adverse Event Reporting System Administrator’s Guide
Workflow tasks
Workflow tasks Workflow 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. 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.
Note:
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. Supporting your work processes 10-5
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 tasks Prerequisites: ■
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:
10-6 Oracle Adverse Event Reporting System Administrator’s Guide
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.
7.
Click the Save button.
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. Supporting your work processes 10-7
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 users Workflow 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 screens The 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.
10-8 Oracle Adverse Event Reporting System Administrator’s Guide
Designing screens
Global screens and fields configuration The 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 Description The 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
Y
Code list, used to populate record group
FIELD VALIDATION CODE_LIST
CODE_LST_SOFT_VAL_ Y FLAG
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
Supporting your work processes 10-9
Designing screens
Table 10–1 (Cont.) Field Attributes Table Field Name
Mod?
Description
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?
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).
VISUAL CONTROLS
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.
10-10 Oracle Adverse Event Reporting System Administrator’s Guide
Designing screens
Table 10–1 (Cont.) Field Attributes Table Field Name
Mod?
Description
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.
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_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
QUERY FIELDS
CUSTOM COMMENTS
CUSTOM_COMMENTS_ Y TEXT
Text describing customization
N
Custom permission type S (System), C (Customer may modify)
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
CUSTOM_PERMSN_ TYPE AUDIT INFORMATION
WDW_ATTRIBUTES Table Description The 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. Table 10–2
Window Attributes Table
Field Name
Mod?
Description
CURRENT_WDW
N
Current window. There are entries here for the main windows as well as the subtabs.
Supporting your work processes 10-11
Designing screens
Table 10–2 (Cont.) Window Attributes Table Field Name
Mod?
Description
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
Modifying the global screens and fields configuration attributes 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, or by selecting Help=>FAT Configuration. The Field Attributes window displays. 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.
Note:
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.
4.
Click the Save button or press the F10 key to save changes. Oracle AERS saves the changes to the database.
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. ■
3.
Window Label: The label that appears on the tab stop
Click the Save button or press the F10 key to save changes. Oracle AERS saves the changes to the database.
Revealing custom fields The custom screens and fields are hidden by default, to reveal them follow these directions: 1.
From Case Browse, select Help=>FAT Configuration.
10-12 Oracle Adverse Event Reporting System Administrator’s Guide
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. 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.
Note:
Workflow-specific screens and fields configuration For 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 Table The 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. Table 10–3
Field Modes 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
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
WINDOW_MODES Table Properties of windows for different Workflow Tasks. There must be an entry for every Workflow Task for every Data Entry window in the WAT.
Supporting your work processes 10-13
Configuring the data entry Navigator panel
Table 10–4
Window Modes Table
Field Name
Mod?
Description
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
Modifying Workflow-specific screen and field configuration To 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.
■
■
■
■
■
■
■
4.
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.
Click the Save button or press the F10 key to save changes.
Configuring the data entry Navigator panel The 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.
10-14 Oracle Adverse Event Reporting System Administrator’s Guide
Configuring the data entry Navigator panel
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 entry For 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.
5.
Key in all fields. ■
6.
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
Click the Save button or press the F10 key to save changes. The new tree name is saved to the database.
Creating Record Groups The 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 Supporting your work processes 10-15
Configuring the data entry Navigator panel
■
4.
Lov Name:
Click the Save button or press the F10 key to save changes. The new tree name is saved to the database.
Creating the SQL statement to display the Navigator view The definition and use of the column is as follows: Column 1: Default Node expansion. Values
Description
1
Expand the node
-1
Collapse the node
0
An end node (not expandable
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. This is sorted as an alpha (character) value so A12 sorts before A2.
Note:
■
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',
10-16 Oracle Adverse Event Reporting System Administrator’s Guide
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. The use of A1 and A2 in the Union’d statements; these control the sort order within the full tree.
Note:
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 constraints It 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).
Supporting your work processes 10-17
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.
10-18 Oracle Adverse Event Reporting System Administrator’s Guide
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 security The 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 objects You can set security on the level of the Oracle AERS sites, user groups, and users.
User groups You 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 Managing Users And User Groups 11-1
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.
Users You 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 security The 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 ownership Every 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 permissions Every 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.
11-2 Oracle Adverse Event Reporting System Administrator’s Guide
Managing Oracle AERS Roles
Oracle Roles Oracle 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/Groups AERS 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 Roles Oracle 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 users Oracle 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 Roles Oracle 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 Managing Users And User Groups 11-3
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. This feature differs from previous releases of AERS, in which you could only confer supervisor privileges by granting the reserved role SUPERVISOR.
Note:
■
■
■
4.
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.
Click the Save button, or press the F10 key, to save the role. Oracle AERS saves the role to the database.
Maintaining user groups A 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). You perform user group maintenance in the local Oracle AERS application.
Note:
This section describes the following user group maintenance tasks: ■
Understanding user group permissions
11-4 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining user groups
■
Adding permissions to a user group
■
Adding user groups
■
Updating user groups
■
Deleting user groups
Understanding user group permissions You 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. 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
Adding permissions to a user group To 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. 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.
Note:
Adding user groups To add a user group: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
2.
Select the User Profile tab from the Administrator Console. Managing Users And User Groups 11-5
Maintaining user groups
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. ■
■
■
5.
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.
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 groups To update a user group: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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 groups You 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").
11-6 Oracle Adverse Event Reporting System Administrator’s Guide
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.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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 users As 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 users AERS 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.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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.
Managing Users And User Groups 11-7
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 passwords When 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 roles Users 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 Roles Every 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.
11-8 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining users
Table 11–2 (Cont.) Baseline Oracle Roles Menu Role
Visible Menus/Permissions
COMMON_MENU_ ENRL
Gives the minimum menu bar: File=>Print Screen, Exit, Window (all), Help (all). Data Mnt=>Change Password (all): All users must have this.
(Oracle menu role)
Optional AERS Roles Table 11–3 lists the optional Oracle Menu Roles you can assign, according to job definition. Table 11–3
Oracle AERS Roles
Menu Role
Visible Menus/Permissions
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
Managing Users And User Groups 11-9
Maintaining users
Table 11–3 (Cont.) Oracle AERS Roles Menu Role
Visible Menus/Permissions (Cont.)
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
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. Menu Role
Permissions
ENREAD
Grants read-only access to Oracle AERS tables for ad hoc query capability (see Ad Hoc section below).
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.
Note:
Other AERS Application Roles Oracle 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. 11-10 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining users
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 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: 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.
Assigning roles to a user The 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: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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.
Managing Users And User Groups
11-11
Maintaining users
Updating user attributes and permissions To update a Oracle AERS user profile: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
2.
Select the User Profile tab from the Administrator Console. The User Maintenance screen displays.
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.
11-12 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining users
Table 11–4 (Cont.) User Attributes and Permissions Option
Description
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.
5.
Click the Save button, or press F10, to save changes. The system saves the user to the database.
User permissions You 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. 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
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. 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.
Note:
Managing Users And User Groups
11-13
Local privacy and security
Local privacy and security Oracle 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 membership The 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 configuration The 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.
11-14 Oracle Adverse Event Reporting System Administrator’s Guide
Local privacy and security
Example 1: Local Privacy configuration for patient name and address In 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 data In 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.
Managing Users And User Groups
11-15
Record-level filtering
Configuration Procedure Creating the Codelist For 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:
3.
4.
■
Enter the Codelist Name and Description.
■
Set the Customization Type to “C” for customizable.
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.
Save the Codelist.
Configuring the Security Codelist To 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.
5.
Save your changes.
Record-level filtering Oracle 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.
11-16 Oracle Adverse Event Reporting System Administrator’s Guide
Record-level filtering
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 components There are three components to the record-level filtering configuration: Authorization Lists These 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 Tasks Any 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 affiliate In 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.
Managing Users And User Groups
11-17
Record-level filtering
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). 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:
Example 2: Investigation filtering for Product Complaint investigation users In 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). 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.
Note:
Configuration Procedure Filtering Records To 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
11-18 Oracle Adverse Event Reporting System Administrator’s Guide
Record-level filtering
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 List The 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.
3.
■
Enter the Codelist Name and Description.
■
Set the Customization Type to “C” for customizable.
Enter codelist values. ■
Enter the names of the Assigned To values as the Code.
■
Enter the Language Code “en”. Managing Users And User Groups
11-19
Record-level filtering
■
Set the User Enterable flag to ’Y’.
■
The Retired Flag should be ’N’.
■
4.
The values of the other attributes are optional.
Save the Codelist.
Creating Roles You 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: –
■
For an Investigations authorization list: –
5.
Set the Country List Flag to ’Y’ for the role.
Set the Assignment Flag to 'Y' for the role.
Save your Role(s).
Assigning Roles Once 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 Task Assigning 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.
11-20 Oracle Adverse Event Reporting System Administrator’s Guide
Managing passwords
Managing passwords Oracle 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 passwords You 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: 1.
Open the Administrator Console by pressing the subsystem button or selecting Maintenance=>Administrator Console.
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.
2.
Select the user from the Navigator panel.
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 Users And User Groups
11-21
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 timeout Oracle 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: 1.
Navigate to the Administrator Console.
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. ■
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. ■
5.
Under Control Value, enter the time in seconds.
Under Control Value, enter the time in seconds.
Close the Administrator Console.
Resetting a user’s password Resetting a password using the Administrator Console Users with administrator privileges can reset another user’s password from within the Administrator Console. To reset a user’s password using the Administrator Console: 1.
Navigate to the Administrator Console.
2.
Select the user from the Navigator panel.
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. Note: The default password is <username123>. See "Assigning Oracle passwords"for more information.
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. 11-22 Oracle Adverse Event Reporting System Administrator’s Guide
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*Plus If 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 Password There are four steps to changing the PORTAL30 password for AERS: 1.
2.
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
c.
Exit SQL*Plus.
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 Users And User Groups
11-23
Managing passwords
3.
4.
c.
Click on the Change Password link at the top right hand side of the page.
d.
Enter the old password and the
e.
Click OK.
f.
Close the browser.
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
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.
Change the stored password for PORTAL30 on the Report Server. a.
Login to the Report Server machine.
b.
Navigate to the
c.
Copy the
d.
Open the
e.
Identify the line: <property name="securityUserid" value="lyKAUY84+Xqn2krjZGGLs0DiBUs1RlY=" confidential="yes" encrypted="yes"/>
f.
Replace the encrypted string for the "value" with the
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
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.
11-24 Oracle Adverse Event Reporting System Administrator’s Guide
12 Data 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 codes Every 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 view You 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 CASE_ID
Value
Description Case ID
Data management 12-1
Duplicate checking
Column Name
Value
Description
VERSION NUMBER
Number
Version #
Duplicate checking Oracle 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 API This section describes what the Duplicate Check API function does, its input parameters, and what it produces as output.
Description The 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 parameters Table 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. 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
12-2 Oracle Adverse Event Reporting System Administrator’s Guide
Duplicate checking
Table 12–1 (Cont.) Input Parameters Parameter
Data
Description
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
Output The 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 logic Duplicate 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 Data management 12-3
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 Cases Clinical 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
12-4 Oracle Adverse Event Reporting System Administrator’s Guide
Copy Case
Product Complaint Cases The 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 Field
Value if Matched
Product Code
2.0
Complaint Code
1.0
Lot Number
1.0
Reporter Last Name (first three letters)
1.0
Copy Case The front-end calls Copy Case, which AERS defines in the function DECopyCase. FUNCTION:
DECopyCase
INPUT:
Case ID, New Case ID
OUTPUT:
Inserts data into tables specified in function.
Generic implementation Table 12–2 lists the data elements that the copy case function copies. Table 12–2
Copy Case Data Elements
Copied Table
Copied Columns
AE_CASES
CASE_ID
DRUG_FORM
CASE_STS
DRUG_DID
CASE_TYPE
DRUG_PROJECT_TID
PROCESS_FLAG
DICT_UNMAPD_FLAG
DELETE_FLAG
GENERIC_NAME
FIRST_RCVD_DT
DRUG_CLASS
VALIDATION_REQD_FLAG
PREFERRED_DRUG_PROJECT_NAME
RECONCILIATION_STS
RISK_FACTOR_CMNT
PROD_CD
PER_SFTY_UP_RPT_CMNT
CASE_OWNER_USR_GRP_ID
PHARMACOVIGILANCE_CMNT
PROJECT_DRUG_NAME
EV_OCC_COUNTRY_CD
Data management 12-5
Copy Case
Table 12–2 (Cont.) Copy Case Data Elements Copied Table
Copied Columns (Cont.)
AE_EVENTS
CASE_ID
CO_ADDED_TERM_FLAG
EVENT_SEQ_NBR
SERIOUS_FLAG
DISPLAY_NBR
FROM_DT
PRIMARY_IND
TO_DT
RPT_VERBTM
ONGOING_FLAG
CO_VERBTM
DURATION
PREFERRED_EVENT_TERM
DURATION_UNIT
BODY_SYSTEM
OUTCOME_CD
SUB_BODY
THERAPY_FLAG
MID_LVL_TERM
THERAPY_TEXT
EVENT_DID
US_UNEXPECTED_FLAG
EVENT_TID
CORE_UNEXPECTED_ FLAG
DICT_UNMAPD_FLAG AE_SUSPECT_ DRUGS
CASE_ID
CUM_DOSE
SUSP_DRG_SEQ_NBR
CUM_DOSE_UNIT
DRUG_NAME
ABATE_FLAG
DRUG_DID
REAPPEARED_FLAG
SUSPECT_DRUG_TID
PRIOR_USE_FLAG
DICT_UNMAPD_FLAG
TOLERATED_FLAG
GENERIC_NAME
RECHALLENGED_FLAG
DRUG_CLASS
DUR_OF_TRTMT_TO_EV
PREFERRED_DRUG_NAME
DUR_OF_TRTMT_TO_EV_UNIT
DISPLAY_NBR
TOTAL_DUR_OF_TRTMT
PRIMARY_FLAG
TOTAL_DUR_OF_TRTMT_UNIT
DRUG_COMPANY_FLAG
ROUTE_CHILD_CD
OVER_COUNTER_FLAG
PURCH_COUNTRY_CD
ACTION_TAKEN
DRUG_INTERACTION_FLAG
REASON_FOR_ACTION
REPORTER_CAUSE_TYPE
LOT_NBR
RELATEDNESS_CD
EXP_DT
RPT_RELATEDNESS_CD
NDC_NBR
CUM_DOSE_CHR
PRODUCT_PROBLEM_FLAG PROD_PROB_QA_NUMBER AE_INDICATIONS
CASE_ID
INDICATION_CODE
SUSP_DRG_SEQ_NBR
DX_DID
INDIC_SEQ_NBR
INDICATION_TID
INDICATION
DICT_UNMAPD_FLAG
12-6 Oracle Adverse Event Reporting System Administrator’s Guide
Copy Case
Table 12–2 (Cont.) Copy Case Data Elements Copied Table
Copied Columns (Cont.)
AE_DOSAGES
CASE_ID
DOSE_STRENGTH
SUSP_DRG_SEQ_NBR
DOSE_STRENGTH_UNIT
DSG_SEQ_NBR
FROM_DT
DOSE
TO_DT
DOSE_UNIT
DURATION
FREQUENCY
DURATION_UNIT
ROUTE
CLOSEST_TO_EV_FLAG
DRUG_FORM
DOSE_CHR DOSE_STRENGTH_CHR
AE_EVENTS_TO_ DRGS
CASE_ID
RPT_RELATEDNESS_CD
SUSP_DRG_SEQ_NBR
US_UNEXPECTED_FLAG
EVENT_SEQ_NBR
CORE_UNEXPECTED_FLAG
RELATEDNESS_CD AE_CASE_RPT_ FRM_LOGS
CASE_ID
PREP_BY_COMPANY
CS_LOG_SEQ_NBR
PREP_BY_CITY_NAME
RCVD_DT
PREP_BY_COUNTRY_CD
RCVD_BY_FRST_NAME
PROCESSED_IN_SFTY_DT
RCVD_BY_LST_NAME
REV_FRST_NAME
RCVD_BY_POSITION
REV_LST_NAME
PREP_DT
REVIEW_DT
PREP_BY_FRST_NAME
LOG_IN_COMMENTS_TEXT
PREP_BY_LST_NAME
Data management 12-7
Data derivation procedures
Table 12–2 (Cont.) Copy Case Data Elements Copied Table
Copied Columns (Cont.)
AE_REPORT_ SOURCES
CASE_ID
RPT_ORG_NAME
RPT_SEQ_NBR
RPT_ADDR1
PRINCIPAL_INVEST
RPT_ADDR2
NON_CO_STUDY_SPONSOR
RPT_ADDR3
RPT_SOURCE_TYPE
RPT_ADDR4
REGISTRY_NAME
RPT_CITY_NAME
REGISTRY_NBR
RPT_STATE_CD
LITERATURE_DESC
RPT_ZIP_CD
LIT_ISSUE_DT
RPT_COUNTRY_CD
LIT_VOLUME
RPT_PHONE
LIT_PAGE
RPT_FAX
RPT_ID
RPT_EMAIL
NON_CO_STUDY_DESC
RPT_OCCUPATION
RPT_FRST_NAME
RPT_SPECIALTY_DESC
RPT_LST_NAME
WRK_HOSP_FLAG
RPT_MID_INITIAL
RPT_IS_PATIENT_FLAG
RPT_TITLE
OTHER_PATIENT_ID
HEALTH_PROF_FLAG CONSUMER_FLAG PRIMARY_REPORTER_IND AE_RLVNT_ APPROVALS
CASE_ID
LIC_NBR
SUSP_DRG_SEQ_NBR
LIC_TYPE
RLVNT_APPR_SEQ_NBR VW_COMPANY_ NARRATIVE, VW_REPORTER_ NARRATIVE
CASE_ID FIELD_NAME FIELD_VALUE
Data derivation procedures Oracle AERS provides two data derivation procedures: Case ID generation and Case data derivations.
Case ID generation An 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.
12-8 Oracle Adverse Event Reporting System Administrator’s Guide
Data derivation procedures
Updating the Case ID generation algorithm Function Name
GENERATECASEID
Return Type
VARCHAR32
Input
None
Output Description
Unique Case ID
Case data derivations The 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 derivations The 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 library The 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 Data management 12-9
Data derivation procedures
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. 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.
Generating the library To 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.
12-10 Oracle Adverse Event Reporting System Administrator’s Guide
Data derivation procedures
Standard derivation procedures Table 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
Fld: Field derivation triggers the derivation. EN: The derivation is not customizable (Core). Stored: Oracle AERS stores the derivation result in the database.
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."
Data management 12-11
Data derivation procedures
Table 12–4 (Cont.) Standard Derivation Procedures Field (Cont.)
Source Fields (Cont.)
Description
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
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.
Event Level Seriousness, Unexpectedness
Any 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.
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
Fld: Field derivation triggers the derivation. EN: The derivation is not customizable (Core). Stored: Oracle AERS stores the derivation result in the database.
MOD_REPORTER_ CAUSE
REPORTER_CAUSE_ TYPE
Fld: Field derivation triggers the derivation. EN: The derivation is not customizable (Core). Stored: Oracle AERS stores the derivation result in the database.
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."
12-12 Oracle Adverse Event Reporting System Administrator’s Guide
Field code lists
Table 12–4 (Cont.) Standard Derivation Procedures Field (Cont.)
Source Fields (Cont.)
Description
Reconciliation Discrepancy
Existence of under Review Cust: The derivation is customizable. PLL: Oracle AERS stores the derivation logic in the Forms Reconciliation library. Discrepancy 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_ Rec: The Record-level triggers the derivation. RPT_ FRM_LOGS records. 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."
Field code lists You 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
Data management 12-13
Field code lists
Adding new code lists If 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 list To add a code list to the Oracle AERS Code List tables: 1.
Launch the Oracle AERS Global Maintenance subsystem.
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. 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.
Note:
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 items To 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
12-14 Oracle Adverse Event Reporting System Administrator’s Guide
Field code lists
AERS also includes specific, reserved languages (RPT, E2B, ISO, and UPL) for coding purposes. ■
■
■
■
6.
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.
Click the Save button, or press F10, to save changes. Oracle AERS saves the new code list item to the database.
Step 3: Create a Record Group Oracle 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.
4.
Click the Save button, or press F10, to save changes.
5.
Close the window.
6.
Exit the Field Attributes form (if done).
Step 4: Assigning code lists to fields To 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.
Data management 12-15
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.
5.
Click the Save button.
Define LOV Column Mapping Once 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 lists In 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
12-16 Oracle Adverse Event Reporting System Administrator’s Guide
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. The Field Attributes form displays.
Updating existing code lists You 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 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.
Updating an item in a code list To update an item in a code list: Data management 12-17
Field code lists
1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab. The Code List Maintenance screen displays.
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.
6.
Click the Save button, or press F10, to save changes. Oracle AERS saves the changes to the database.
Retiring code list values You 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: 1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab from the main window. The Code List Maintenance screen displays.
3.
Select the code list containing the code you want to retire. The code information displays.
4.
Select the code you want to retire.
5.
Click the Retired checkbox to display a check mark.
6.
Click the Save button, or press F10, to save changes.
Reactivating retired individual code list items To reactivate a retired item in a code list: 1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab from the main window. The Code List Maintenance screen displays.
3.
Select the code list containing the code you want to reactivate. The code information displays.
4.
Select the code you want to reactivate.
5.
Click the Retired checkbox to remove the retired check mark.
6.
Click the Save button, or press F10, to save changes.
Deleting code lists To delete a code list: 12-18 Oracle Adverse Event Reporting System Administrator’s Guide
Edit checks
1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab from the main window. The Code List Maintenance screen displays.
3.
Select the code list you want to delete.
4.
Click the Delete button. The code list disappears from the screen.
5.
Click the Save button, or press F10, to save changes. 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 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.
To delete an item in a code list: 1.
Launch the Oracle AERS Global Maintenance subsystem.
2.
Select the Code Lists tab from the main window. The Code List Maintenance screen displays.
3.
Select the code list containing the code you want to delete.
4.
Click the Delete button. The code disappears from the screen.
5.
Click the Save button, or press F10, to save changes. Oracle AERS does not prompt you, and deletes the code list value from the database.
Edit checks Edit 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 checks Field 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
Data management 12-19
Edit checks
checks must be performed at the record-or case-level (wherever is appropriate to that check). Record checks Record checks fire when the user modifies any data in a record and shifts the focus outside the record. Case Save Case Save fires when the user has modified any data in the case and explicitly invokes the save option. Case Exit Case 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 Checking This process runs in the background from the Oracle AERS batch edit report. All Soft edit checks fire in batch mode.
Updating the edit check program You 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 12–5
CustomEditRules Parameters
Parameter
Data Type
Description
ivRecordString/ IN VARCHAR2 ivCaseID
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)
IonGrandChildS IN OUT eq Nbr 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
Table descriptions This section describes the RULE_ATTRIBUTES table and the RULE_FIRING_MODES table. 12-20 Oracle Adverse Event Reporting System Administrator’s Guide
Edit checks
RULE_ATTRIBUTES table The 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. 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)
RULE_FIRING_MODES table This table contains Workflow Tasks in which the rule fires. This table is an intersection table between RULE_ATTRIBUTES and DATA_ENTRY_MODES. 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.
Note:
Table 12–7
RULE_FIRING_MODES Table
Field Name
Description
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)
Data management 12-21
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. 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
(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. TABLE_NAME
RULE_NAME
DE_MODE
RECORD_STS
AE_CASE_RPT_FRM_ LOGS
PREP_DATE_AFTER_ RCVD_ DATE
LOGIN
N
AE_CASE_RPT_FRM_ LOGS
PREP_DATE_AFTER_ RCVD_ DATE
LOGIN
U
AE_CASE_RPT_FRM_ LOGS
PREP_DATE_AFTER_ RCVD_ DATE
DE
U
AE_CASE_RPT_FRM_ LOGS
PREP_DATE_AFTER_ RCVD_ DATE
ASSESS
U
Spell Check The standard Oracle AERS configuration supports spell check using Microsoft Word from a user’s desktop machine via ActiveX. Oracle AERS is also configured to
12-22 Oracle Adverse Event Reporting System Administrator’s Guide
Spell Check
integrate with JSpell. However, it must be purchased by your company and installed on the server.
Configuring for Microsoft Word If 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. 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.
Installing JSpell in Oracle AERS This 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. <806_Home> is the Oracle 806 Home of the 9iAS, e.g. D:\Oracle\806)
Note:
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
Data management 12-23
Reconciliation
■
log=<806_Home>\\FORMS60\\java\\jspell.log Note:
5.
In the
■
6.
7.
The double back-slashes are required (for this file only).
#JSpell servlet.jspell.initArgs=propertiesFile=<806_ Home>\forms60\server\jspell.properties servlet.jspell.code=com.wallstreetwise.app.jspell.domain.net.JSpellServlet
In directory
#JSpell
■
wrapper.classpath=<806_Home>\forms60\java\JSpellIntegration.jar
■
wrapper.classpath=<806_Home>\forms60\java\jspell2w_java11.jar
Restart the Apache Server (OracleiSuitesHTTPServer) on the 9iAS application server.
AS10g Forms Server configuration Edit the file formsweb.cfg in directory
1.
■
2.
archive_jini= f90all_jinit.jar,opaicons.jar,aersicons.jar,timeout.jar,jspell2n_ java11.jar, JSpellIntegration.jar
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.
Reconciliation The 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 Reconciliation You 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.
12-24 Oracle Adverse Event Reporting System Administrator’s Guide
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.
Data management 12-25
Reconciliation
Table 12–8 (Cont.) Reconciliation Rules Rule Name
Condition
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.
Staging tables The 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 table This reconciliation table contains the case information for the patient. Table 12–9
RCN_CASES Table
Field Name
Description
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
12-26 Oracle Adverse Event Reporting System Administrator’s Guide
Reconciliation
Table 12–9 (Cont.) RCN_CASES Table Field Name
Description
CENTER_ID
Code corresponding to the Study Center where the patient was treated
RCN_PATIENT table This reconciliation table contains the patient information. Table 12–10
RCN_PATIENT Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
STUDY_ID
Enrolled study/protocol number
CENTER_ID
Code corresponding to the Study Center where the patient was treated
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
RCN_PATIENT_VITALS table This reconciliation table contains vitals about the patient such as height and weight.
Data management 12-27
Reconciliation
Table 12–11
RCN_VITALS Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
STUDY_ID
Enrolled study/protocol number
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
RCN_PT_AE_PROFILE table This reconciliation table contains patient adverse event information. Table 12–12
RCN_PT_AE_PROFILE Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
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
12-28 Oracle Adverse Event Reporting System Administrator’s Guide
Reconciliation
Table 12–12
(Cont.) RCN_PT_AE_PROFILE Table
Field Name
Description
RELATEDNESS_CD
Indicates an assessment as to whether the symptom or diagnosis is related to the suspect drug
RCN_PT_CAUSE_DEATH table This reconciliation table contains patient cause of death. Table 12–13
RCN_PT_CAUSE_DEATH Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
STUDY_ID
Enrolled study/protocol number
CENTER_ID
Code corresponding to the Study Center where the patient was treated
CAUSE_OF_DEATH_ CODE
The ICD code for the cause of death
CAUSE_OF_DEATH
Text describing the cause of death
RCN_PT_DOSING table This reconciliation table contains patient dosing information. Table 12–14
RCN_PT_DOSING Table
Field Name
Description
PATIENT_ID
The Drug Company Patient ID number if the event reported occurs during a company-sponsored clinical trial
STUDY_ID
Enrolled study/protocol number
CENTER_ID
Code corresponding to the Study Center where the patient was treated
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
Data management 12-29
Clinical data extract file
Table 12–14
(Cont.) RCN_PT_DOSING Table
Field Name
Description
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
Clinical data extract file The 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:
12-30 Oracle Adverse Event Reporting System Administrator’s Guide
Clinical data extract file
Column_Name1,,Column_Name3.
Coded field translations Oracle 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 program Clinical 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.
Data management 12-31
Clinical data extract file
12-32 Oracle Adverse Event Reporting System Administrator’s Guide
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
Overview The Case Browse configuration is managed in four tables: Code Lists, Data Entry Modes, Field Attributes, and Field Modes.
Modes Each 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:
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.
Field Attributes The 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:
Configuring Case Browse
13-1
Overview
Attributes
Req?
Description
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.
Relevant Field Modes Each 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:
Attributes
Req?
Description
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
13-2 Oracle Adverse Event Reporting System Administrator’s Guide
Adding or Updating a Custom Browse Configuration
Adding or Updating a Custom Browse Configuration To 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: ■
■
2.
Code: Name of the Case Browse Mode (e.g. BRW-
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. Note:
You should only perform this step when users are off the
system.
6.
a.
Launch the Workflow Configuration form from the AERS Home Page.
b.
Select Rebuild Browse Config from Actions menu
c.
Exit Workflow Configuration
Configure the Default Case Browse for each user using the User administration screen on the AERS Administration Console.
Fields Available for Configuration The following Field Attributes items are available for Case Browse Configuration:
ITEM_NAME
TABLE_NAME
FIELD_NAME
SCREEN_LABEL
ACIS_FLAGS
AE_CASES
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
ACIS
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
PT_RACE
AE_CASES
Age PT_RACE_CD
13-4 Oracle Adverse Event Reporting System Administrator’s Guide
Race
Fields Available for Configuration
ITEM_NAME
TABLE_NAME
FIELD_NAME
SCREEN_LABEL
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
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
INITIAL_RECEIVE_DATE EC_CONTACT_LOG
Serious
Init/Follow-up 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
Configuring Case Browse
13-5
Out-of-the-Box Case Browse Configuration
ITEM_NAME
TABLE_NAME
FIELD_NAME
SCREEN_LABEL
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#
Out-of-the-Box Case Browse Configuration There 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;
Field Attributes
Item Name
Field Modes
Table Name
Field Name
Dic Query Text
BRW DEFAULT: Default modes
13-6 Oracle Adverse Event Reporting System Administrator’s Guide
Sub Query Text
X Pos
Y Pos
Field Wdth
Out-of-the-Box Case Browse Configuration
Field Attributes
Item Name
Field Modes
Table Name
Field Name
Dic Query Text
Sub Query Text
SORT_SEQ_ NBR
X Pos
Y Pos
Field Wdth
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
481
59
63
PROD_CD
AE_CASES
543
59
98
162
70
30
NEXT_ TASK_ DUE
192
70
75
AE_CASES EV_OCC_ COUNTRY_CD
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 405 CONTAC T_SEQ_ NBR
70
76
CORE_ AE_CASES UNEXPECTED _ FLAG
CORE_ UNEXPEC TED_ FLAG
481
70
32
US_ AE_CASES UNEXPECTED _ FLAG
US_ UNEXPEC TED_ FLAG
513
70
31
CO_VERBTM
CO_ VERBTM
543
70
98
decode(DIED_ FLAG,'Y','DEATH ',decode(LF_ THREAT_ FLAG,'Y', 'LIFETHREAT',de code(SERIOUS_ FLAG,'Y','SERIO US','N','NOT-SERI OUS',NULL))) PROD_CD
PICKED_FLAG NEXT_TASK_ DUE
VW_NEXT_ TASK
AE_EVENTS
and DISPLAY _NBR = 1
Configuring Case Browse
13-7
Out-of-the-Box Case Browse Configuration
Field Attributes
Field Modes
Item Name
Table Name
ACIS_FLAGS
AE_CASES
PRIORITY
AE_CASES
Field Name
Dic Query Text
Sub Query Text
X Pos
Y Pos
Field Wdth
162
81
30
CASE_ PRIORITY
192
81
75
RPT_SOURCE_ TE_ TYPE PREFERRED_ SOURCE
PREFERRE D_ SOURCE
267
81
77
PATIENT_ID
AE_CASES
PATIENT_ ID
344
81
61
RECEIVED_ DATE
EC_CONTACT_ LOG
405
81
76
REPORTER_ CAUSE_ TYPE
AE_CASES
REPORTE R_CAUSE_ TYPE
481
81
63
EV_ONSET_ DATE
AE_CASES
EV_ ONSET_ DT
543
81
98
162
59
30
decode(ADVERS E_EVENT_FLAG, 'Y','A') || decode( PRODUCT_ COMPLAINT_ FLAG,'Y', 'C') || decode(MEDICA L_ INQUIRY_ FLAG, 'Y','I') || decode( SERVICE_ COMPLAINT_ FLAG,'Y','S')
max(RECEIVE_ DATE)
BRW-PC: Complaints SORT_SEQ_ NBR 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
344 decode(count(*),0, and 'N','Y') DATE_ COMPLE TED is NULL
59
76
420
59
76
OPEN_ TE_ CORRECTIVE_ CORRECTIVE_ ACTIONS ACTIONS
CASE_STS
AE_CASES
CASE_STS
13-8 Oracle Adverse Event Reporting System Administrator’s Guide
Out-of-the-Box Case Browse Configuration
Field Attributes
Field Modes
Item Name
Table Name
SERIOUS_ FLAG
AE_CASES
PROD_CD
AE_CASES
Field Name
Dic Query Text
Sub Query Text
decode(DIED_ FLAG,'Y','DEATH ', decode(LF_ THREAT_ FLAG,'Y', 'LIFE-THREAT',d ecode( SERIOUS_ FLAG,'Y','SERIO US','N','NOT-SERI OUS',NULL))) PROD_CD
PICKED_FLAG
X Pos
Y Pos
Field Wdth
481
59
63
496
59
145
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_ INVESTIGATI ONS
PC_ INVESTIGATIO NS
344 decode(count(*),0, and 'N','Y') DATE_ COMPLE TED is NULL
70
76
INITIAL_ RECEIVE_ DATE
EC_CONTACT_ LOG
RECEIVE_ DATE
order by 420 CONTAC T_SEQ_ NBR
70
76
CORE_ AE_CASES UNEXPECTED _ FLAG
CORE_ UNEXPEC TED_ FLAG
481
70
32
COMPLAINT_ CODE
COMPLAI NT_CODE
496
70
145
513
70
31
543
70
98
AE_SUSPECT_ DRUGS
US_ AE_CASES UNEXPECTED _ FLAG
US_ UNEXPEC TED_ FLAG
CO_VERBTM
CO_ VERBTM
AE_EVENTS
and DISPLAY _NBR = 1
and DISPLAY _NBR = 1
Configuring Case Browse
13-9
Out-of-the-Box Case Browse Configuration
Field Attributes
Field Modes
Item Name
Table Name
ACIS_FLAGS
AE_CASES
PRIORITY
AE_CASES
RPT_SOURCE_ TE_ TYPE PREFERRED_ SOURCE
Field Name
Dic Query Text
Sub Query Text
X Pos
Y Pos
Field Wdth
162
81
30
CASE_ PRIORITY
192
81
75
PREFERRE D_ SOURCE
267
81
77
decode(ADVERS E_EVENT_ FLAG,'Y','A') || decode(PRODUC T_ COMPLAINT_ FLAG,'Y','C') || decode(MEDICA L_INQUIRY_ FLAG,'Y','I') || decode(SERVICE_ COMPLAINT_ FLAG,'Y','S')
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, and 'N','Y') DATE_ RETURN ED is NULL
344
81
76
RECEIVED_ DATE
EC_CONTACT_ LOG
max(RECEIVE_ DATE)
420
81
76
REPORTER_ CAUSE_ TYPE
AE_CASES
REPORTE R_CAUSE_ TYPE
481
81
63
EV_ONSET_ DATE
AE_CASES
EV_ ONSET_ DT
496
81
145
13-10 Oracle Adverse Event Reporting System Administrator’s Guide
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 configuration This section describes the two principal query configuration tasks: Modifying existing query configuration and Adding new query fields.
Modifying existing query configuration You 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.
Case Data Query 14-1
Query configuration
Table 14–1
Configuring Query Fields
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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.
14-2 Oracle Adverse Event Reporting System Administrator’s Guide
Query configuration
Table 14–3 (Cont.) Configuring Query Appearance Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Field Name
Mod?
Description
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
Case Data Query 14-3
Query configuration
Table 14–8 (Cont.) Query Window Configuration Field Name
Mod?
Description
HELP_CONTEXT_ID
N
Tag to support the help facility
HELP_TEXT
Y
Modifying site
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. The Field Attributes form displays.
2.
Configure the screens and fields by performing one or more of the following tasks: ■ ■
■
■
■
3.
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).
Click the Save button or press the F10 key to save your changes.
Adding new query fields When 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 views In 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. If you link to an external system, you must create a public link and grant READ access to that link to the ENUSER role.
Note:
Once you create the view, you must introduce the join criteria from Oracle AERS to the external view.
14-4 Oracle Adverse Event Reporting System Administrator’s Guide
Query configuration
Adding the Query Table Join The 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. 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.
Note:
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.
5.
Close the window.
Adding a new field to the query screens Once 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. The Field Attributes form displays.
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.
Case Data Query 14-5
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. Caution: DO NOT change the values of the Window Name, Block Name and Item Name. These are not configurable.
5.
Click the Save button, or press the F10 key, to save the newly created field.
Adding an Exclude Flag to a new block The 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: ■
■ ■
4.
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.
Click the Save button, or press the F10 key, to save the newly created field.
Adding custom queries Once 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.
14-6 Oracle Adverse Event Reporting System Administrator’s Guide
Adding custom queries
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 Console To manage user favorites from the Administrator Console: 1.
Navigate to 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.
Case Data Query 14-7
Adding custom queries
14-8 Oracle Adverse Event Reporting System Administrator’s Guide
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 Parameters The 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.
E2B Configuration 15-1
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 processing The 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 Table The 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.
15-2 Oracle Adverse Event Reporting System Administrator’s Guide
Export processing
Flag
Explanation
Action
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 If ‘Y’ the case version is included. version number based If ‘N’, the case version field is left upon workflow events as blank. 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.
USE_LONG_CASEID
The EMEA requires the safetyreportid be a concatenation of three data values, separated by dashes:
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 If ‘Y’, the reactionmeddraversionpt the tag is included in the output. reactionmeddraversionpt If ‘N’, the tag is not included. tag included in the file.
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.
E2B Configuration 15-3
Export processing
Flag
Explanation
Action
INCLUDE_EDIFACT_ ENVELOPE
This flag modifies the output to meet EDIFact/FDA requirements.
If ‘Y’, The file type suffix is set to.edi instead of the usual.xml.
EFIFACT specific data is added to This option works in the EDI header and trailer. conjunction with the EDI_ Specifically, HEADER and TRAILER. 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.
15-4 Oracle Adverse Event Reporting System Administrator’s Guide
Export processing
Flag
Explanation
Action
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
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
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 If ’Y’ and there is no E2B decode for published list, it is output the dose unit it is suppressed from into the drug info field. the dose unit field
DOSEUNIT_TO_ DOSETEXT
If a dose unit is not in the If ’Y’ and there is no E2B decode for published list, it is output the dose unit it is suppressed from the dose unit field into the dose text field.
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
INDICATION_LABEL
The prefix for unmapped This value is prefixed to the indications when they are unmapped indications when they converted to free text. 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
This value is prefixed to the unmapped medical history terms when they are written to the patientmedicalcomment tag.
The prefix for unmapped medical history terms when they are converted to free text.
E2B Configuration 15-5
Import processing
Flag
Explanation
Action
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
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 Y - If a recipient’s gateway is down, the E2B message or the the recipient gateway is acknowledgement is not written to down. 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 AERS 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 15-6 Oracle Adverse Event Reporting System Administrator’s Guide
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.
4.
Click the Save button, or select File=>Save, to save your changes. The sender is saved to the database.
Import Rules This 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_RULES The E2B_IMPORT_RULES table contains the sender-specific import rules configuration. Flag
Explanation
Action
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.
E2B Configuration 15-7
Import processing
Flag
Explanation
USE_SENDER_RECEIVE_ If the sender is a part of DATE the user’s organization or an agent (such as a CRO), the clock should start when the sender learned of the cases.
Action 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.
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. 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.
15-8 Oracle Adverse Event Reporting System Administrator’s Guide
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
Flag
Explanation
Action
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.
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.
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:
IMPORT_EVENTS_TO_ DRUGS
NORMALIZE_DRUGS
If “N”, the report is processed without checking the version number.
If “N” the data is included in the case comments only.
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 This directory must be defined in to place acknowledgment the util_file_dir parameter in the messages. 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 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
E2B Configuration 15-9
Import processing
Flag
Explanation
Action
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.
If “Y”, the import creates a reportability record to store the license number.
If “N”, the license number in the The E2B format includes a input is treated as a non-importable license number for each field and it is stored in the case drug. This field is the comments. license number that the drug was administered under. CREATE_REGISTRY_ SOURCE
This flag is reserved for a If ‘Y’ the import creates a Report_ possible enhancement. It Source record with a type of “R”, is not implemented in 4.5. for Registry. Use the sender fields to fill in the details of this Report The E2B specifications Source record. distinguish between the If “N” the import does not create a role of primary sources registry source record. 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.
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.
Pre-import user exit If 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,
15-10 Oracle Adverse Event Reporting System Administrator’s Guide
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 Mapping Oracle 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 Fields Many 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 Table E2B 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 Configuration 15-11
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. 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.:
Other Case References AERS 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: Tag
OTHER_SOURCE_TYPE
safetyreportid
E2B
companynumb
CO
duplicatenumb
DUP
authoritynumb
AUT
othernumb
OTH
patientspecialistrecordnumb
SPN
patienthospitalrecordnumb
HPN
localreportnumb
RCV
safetyreportversion
VER
patientgpmedicalrecordnumb
GPN
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 Frequency The 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
15-12 Oracle Adverse Event Reporting System Administrator’s Guide
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 Features Once 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
E2B Configuration 15-13
E2B Automation Features
simultaneously. If two such processes start they should not interfere with each other's work. Gateway down This 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 Processing The 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
15-14 Oracle Adverse Event Reporting System Administrator’s Guide
E2B Automation Features
E2B_LOG Column
Tag or Notes
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.
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_Import The 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.
E2B Configuration 15-15
E2B Automation Features
E2B_LOG The E2B_LOG table logs automated import and export actions at a file level.
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 C = Completed A=Aborted. fail Processing was stopped programmatically without completing. F=Failed Processing was stopped because of an Oracle exception.
ERROR_CODE
The oracle error number
ERROR_MESSAGE
Error message
MESSAGE_TYPE
The type of message such as E2B or acknowlegementacknowl edgement
Usually null if the operation completed normally, e.g. ORA-20001
The value associated with the messagetype tag of the file being processed. ICHICSR ICHICSRACK
MESSAGE_NUMBER
The E2B message number.
NUMBER_OF_ REPORTS
The number of safety reports in the message.
The value associated with the messagenumb tag of the file being processed
Error handling The 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.
15-16 Oracle Adverse Event Reporting System Administrator’s Guide
E2B Automation Features
■
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 Automation The 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 directories E2B 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 permissions The 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('
Creating the database job The 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.
E2B Configuration 15-17
E2B Automation Features
15-18 Oracle Adverse Event Reporting System Administrator’s Guide
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 templates To 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. 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.
Note:
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.
Creating and managing document templates 16-1
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 template Once 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
Defining the template in the LETTERS table The 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.
16-2 Oracle Adverse Event Reporting System Administrator’s Guide
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 reports Oracle 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 Server To 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.
Managing programs and reports 17-1
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 AERS Most 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. Report maintenance is performed in the local Oracle AERS application.
Note:
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.
3.
Key in all fields.
4.
Do either of the following:
17-2 Oracle Adverse Event Reporting System Administrator’s Guide
Defining report parameters
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.
5.
Click the Save button. Oracle AERS saves the Report and Report Parameters to the database.
Defining report parameters All 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: 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.
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.
Managing programs and reports 17-3
Deleting reports
■
3.
# 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).
Click the Save button. Oracle AERS saves the report parameter to the database.
Deleting reports You can remove reports from the Oracle Report Server or in Oracle AERS.
Removing reports From the Portal Reports Security Registry To 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 AERS Before 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.
4.
Click the Delete button. The report disappears from the screen.
5.
Click the Save button. You do not receive a prompt. Oracle AERS deletes the report from the database.
Configuring Oracle AERS reports While external authorities largely dictate the format of each regulatory report, there is considerable variation in the approaches taken by companies in populating the report
17-4 Oracle Adverse Event Reporting System Administrator’s Guide
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 reports Oracle 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 values The 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
Managing programs and reports 17-5
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 parameters Program (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) Note:
The column must have the alias COL1 defined.
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-validation These 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. 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)
17-6 Oracle Adverse Event Reporting System Administrator’s Guide
Configuring report parameter cross-validation
Table 17–1 (Cont.) Descriptions of validation functions Validation Functions
Description
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
There is also a helper procedure in the RPCK package that is useful when you write your own report parameter validation function. Table 17–2
Helper procedure for report parameter validation
Validation Functions
Description
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.
Examples 1. 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.
Managing programs and reports 17-7
Customizable views used by reports
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.
Note:
Client extensions When 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 reports For more detailed information on the customizable views used by reports, see the Oracle AERS Reports Technical Reference Manual (TRM).
17-8 Oracle Adverse Event Reporting System Administrator’s Guide
Adding the company logo for MedWatch report
Configuring ad hoc reporting tools Clients 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 report The 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.
Managing programs and reports 17-9
Adding the company logo for MedWatch report
17-10 Oracle Adverse Event Reporting System Administrator’s Guide
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 configuration Oracle 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
Submission management
18-1
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 Wizard This 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.
18-2 Oracle Adverse Event Reporting System Administrator’s Guide
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 Rules Oracle 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 Syntax Oracle 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. Submission management
18-3
Maintaining Reportability Rules
■
■
■
■
■
■
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 criteria The 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.
4.
Click the Save button, or select File=>Save, to save your changes.
18-4 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining Reportability Rules
Creating or modifying a Reportability Rule Template Oracle 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). 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:
6.
Click the Save button, or select File=>Save, to save your changes.
Applying a Reportability Rule Template You 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.
6.
Click the Save button, or select File=>Save, to save your changes. When you Apply a template, all existing reportability rules for the matching Agency/License are over-written. You cannot undo the action.
Note:
Submission management
18-5
Maintaining Agency Reports
Managing individual reportability for an Approval The 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. 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:
7.
Click the Save button, or select File=>Save, to save your changes. and close the window.
Maintaining Agency Reports An 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). You can perform agency maintenance using the Oracle AERS Global Maintenance subsystem.
Note:
18-6 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining Agency Reports
Adding Agencies/Reports To 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.
4.
Click the Save button, or select File=>Save, to save your changes. The Agency is saved to the database.
Updating and deleting Agencies and Reports To 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.
5.
Click the Save button, or select File=>Save, to save your changes. 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.
3.
Click the Save button, or select File=>Save, to save your changes. 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.
Submission management
18-7
Maintaining Agency Reports
Field
Data Type
Notes
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.
18-8 Oracle Adverse Event Reporting System Administrator’s Guide
Maintaining Agency Reports
Field
Data Type
Notes
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_ Character SUBMISSIONS_PROC
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.
Submission management
18-9
Maintaining Agency Reports
18-10 Oracle Adverse Event Reporting System Administrator’s Guide
19 Oracle 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 Functionality The 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 Columns A 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 Oracle AERS dictionary architecture
19-1
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 TMS AERS 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 Functions The following list describes the AERS functions: ■
Case term classification
■
High Level Term Reporting
■
Dictionary Queries
■
Derived Unexpectedness
■
Omissions
AERS Dictionary API Definition This 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. Oracle does not guarantee that the API will not change in future releases of AERS.
Note:
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
19-2 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
■
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 Model A 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.
Definitions TID: 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 Domains AERS 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 Function Purpose: 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. Oracle AERS dictionary architecture
19-3
AERS Dictionary API Definition
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 Function Purpose: 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_DOMAINS This view is used by AERS to display a pick list of available domains. AERS selects distinct domain_id, name. 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.
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.
19-4 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
The following table shows the triggering action and the API function that is called. 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
E2B import The 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 Function Purpose: 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. Note:
This logic will not work with the new WHO Drug schema.
Then call TMS_USER_FULLAUTOCOADE. ClassifyTerm. Finally, compare the list of Active substances with the list in V_INGREDIENTS. Parameters:
Oracle AERS dictionary architecture
19-5
AERS Dictionary API Definition
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.
Return Value: 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.
Batch Reclassify Batch 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 Procedure BatchReclassify 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.
19-6 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
Specification: procedure BatchReclassify (pqid process_queue.queue_id%type, preasoncode varchar2, pOnlyDictionaryChanges varchar2, pAllCases varchar2, pCasesClassified OUT pls_integer, pTermsClassified OUT pls_integer); Parameter: Name
Values and Purpose
pqid
The QID of the report
preasoncode
A reason code is required when the case is locked.
pOnlyDictionaryChange s
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.
Reporting and High Level Term Derivation The 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.
Oracle AERS dictionary architecture
19-7
AERS Dictionary API Definition
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. 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.
V_ACTIVE_SUBSTANCES This 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. 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_ Varchar2 TYPE Substance_Name
This field is in the view because of its potential to support drug device combo products.
Varchar2
V_SPEC_CAT You 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. 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.
SPECIAL_CATEGORY Varchar2 SPECIAL_ CATEGORY_CODE
Number
AERS Dictionary Query An 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
19-8 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
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 Function When 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
Oracle AERS dictionary architecture
19-9
AERS Dictionary API Definition
AERS Parameter
Notes
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.
Dictionary Search Dialog Box For 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 Unexpectedness In 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.
19-10 Oracle Adverse Event Reporting System Administrator’s Guide
AERS Dictionary API Definition
Dictionary Content Views There 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_TERMS This 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. Column Name
Data Type
Purpose
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
V_PRODUCT_NAMES This view returns a list of all product names in the drug dictionary that are valid for data entry. 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.
Oracle AERS dictionary architecture 19-11
AERS TMS Interface Module
V_REGULATORY_GROUP_NAMES This view returns a list of all regulatory group names in the dictionary. It is used to validate the COMPANY_DRUGS table. Column Name
Data Type
Notes
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.
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. Module
Path
Dictionary Creation and Load Scripts
aers\database\configuraation\tms
19-12 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
Module
Path
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.
AERS Standard Dictionaries in TMS AERS 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 Drug The 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 Name The 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 Oracle AERS dictionary architecture 19-13
AERS TMS Interface Module
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 Name The 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 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.
The AERS WHO Drug implementation makes use of the TMS values associated with each term. The Who Drug data load populates these values.
19-14 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
AERS Enhancements to MedDRA AERS 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 modes There 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 Mode Classic 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 Mode Clinical 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 Example A 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 Mapping The 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.
Oracle AERS dictionary architecture 19-15
AERS TMS Interface Module
AERS
TMS
Notes
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.
Interface Module Tables This section defines tables that are used to map AERS data to TMS data. They are only used by API code.
AERS_TMS_DICTIONARY_COLUMNS Table When 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. Column Name
Data Type
Notes
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.
AERS_ DICTIONARY_ COLUMN_ID
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.
19-16 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
Column Name
Data Type
Notes
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.
AERS_TMS_TERM_ROWS The 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.
Column Name
Data Type
Usage
AERS_ DICTIONARY_ COLUMN_ID
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.
AERS Controls Table Entries The TMS interface makes use of the AERS CONTROLS table. The following tables lists the control ids used in the TMS interface. 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.
Oracle AERS dictionary architecture 19-17
AERS TMS Interface Module
Notes on AERS_Dictionary_API Package This 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.
GetLastOmissionKey ClassifyTerm 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. 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.
ReclassifyCase This 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.
Search The 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. 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
19-18 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
TMS Parameter Name
Derivation
pLanguage
pUDparam1
pApproved
pUDparam2
pScope
pUDparam3
pInconsFlag
pUDparam4
pRecordLimitn
pUDparam5
pStartLevelId
pStartlevel
pReverseAtLevelID
pHighestLevel
V View Implementation The 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 Form The 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 Box The 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 Views From 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 Install The 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.
Oracle AERS dictionary architecture 19-19
AERS TMS Interface Module
TMS Configuration and Dictionary Loading The 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 Install The 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 Labels The 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 Versions The 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.
19-20 Oracle Adverse Event Reporting System Administrator’s Guide
AERS TMS Interface Module
Label Maintenance Form The 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.
Oracle AERS dictionary architecture 19-21
AERS TMS Interface Module
19-22 Oracle Adverse Event Reporting System Administrator’s Guide
20 Architectural details This chapter describes three features of the Oracle AERS architecture: ■
Audit trail
■
Data model naming conventions
Audit trail Case-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 conventions The following prefixes apply to case-related data within the data model. No Prefix Control, configuration and list tables.
Architectural details 20-1
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.
20-2 Oracle Adverse Event Reporting System Administrator’s Guide
A Oracle 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 Clinical Oracle 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 group 1.
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.
Oracle Clinical configuration A-1
Setting up value lookups from Oracle Clinical
It is not important which field is displayed on the Field Attributes form, because Record Groups are not directly related to fields.
Note:
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.
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:
7.
Commit.
Step 2: Assign record groups to fields 1.
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.
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.
Note:
Step 3: Define the LOV columns Click 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
A-2 Oracle Adverse Event Reporting System Administrator’s Guide
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 lookups This 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_STUDIES This section describes the definition and field LOV mappings for record group OCL_ STUDIES.
Record group definition 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'
Field LOV Mappings The following tables contain the field LOV mappings for the OCL_STUDIES record group. Each table title lists the form, window, and item. Table A–1
E_ENTRY, Demographics, STUDY_ID
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID
2
Description
600
Table A–2
E_ENTRY, Case Login, STUDY_ID_M0
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID
Oracle Clinical configuration A-3
Specific Oracle lookups
Table A–2 (Cont.) E_ENTRY, Case Login, STUDY_ID_M0 Column
Title
Width
Return Item
2
Description
60
Table A–3
Q_QUERY, Demographics, STUDY_ID_M0
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID_M0
2
Description
600
Table A–4
Q_QUERY, Case Login, STUDY_ID_M1
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID_M1
2
Description
600
Table A–5
Q_QUERY, Quick Query, STUDY_ID_M2
Column
Title
Width
Return Item
1
Study
200
AE_CASES.STUDY_ID_M2
2
Description
600
Record group for centers: OCL_SITES This section describes the definition and field LOV mappings for record group OCL_ SITES.
Record group definition
Codelist
LOV name
Codelist executable text
OCL_SITES
COMMON_3_COLUMN_LOV SELECT B.STUDY_SITE COL1,
FROM
C.CITY
COL2,
C.COUNTRY
COL3
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
Field LOV mappings The following tables contain the field LOV mappings for the OCL_SITES record group. Each table title lists the form, window, and item.
A-4 Oracle Adverse Event Reporting System Administrator’s Guide
Specific Oracle lookups
Table A–6
E_ENTRY, Demographics, CENTER_ID
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID
2
City
300
3
Country
100
Table A–7
E_ENTRY, Case Login, CENTER _ID_M0
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M0
2
City
300
3
Country
100
Table A–8
Q_QUERY, Demographics, CENTER_ID
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID
2
City
300
3
Country
100
Table A–9
Q_QUERY, Case Login, CENTER _ID_M2
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M
2
City
300
3
Country
100
Table A–10
Q_QUERY, Quick Query, CENTER _ID_M1
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M1
2
City
300
3
Country
100
Record group for Investigators: OCL_INVESTIGATORS This section describes the definition and field LOV mappings for record group OCL_ INVESTIGATORS.
Oracle Clinical configuration A-5
Specific Oracle lookups
Record group definition Codelist
LOV Name
Codelist Executable Text
OCL_ INVESTIGATO RS
COMMON_5_COLUMN_LOV SELECT C.INVESTIGATOR COL1,
FROM
C.LAST_NAME
COL2,
C.FIRST_NAME
COL3,
C.CITY
COL4,
C.COUNTRY
COL5
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 A.CLINICAL_STUDY_ID = B.CLINICAL_ STUDY_ID AND
B.INVESTIGATOR_ID = C.INVESTIGATOR_ID
Field LOV Mappings The following tables contain the field LOV mappings for the OCL_INVESTIGATORS record group. Each table title lists the form, window, and item. Table A–11
E_ENTRY, Demographics, INVEST_ID
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID
2
Last Name
200
3
First name
200
4
City
300
5
Country
100
Table A–12
E_ENTRY, Case Login, INVEST_ID_M0
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID
2
Last Name
200
3
First name
200
4
City
300
5
Country
100
Table A–13
Q_QUERY, Demographics, INVEST_ID
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID_M0
2
Last Name
200
A-6 Oracle Adverse Event Reporting System Administrator’s Guide
Specific Oracle lookups
Table A–13 (Cont.) Q_QUERY, Demographics, INVEST_ID Column
Title
Width
Return Item
3
First name
200
4
City
300
5
Country
100
Table A–14
Q_QUERY, Case Login, INVEST_ID_M2
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID_M2
2
Last Name
200
3
First name
200
4
City
300
5
Country
100
Table A–15
Q_QUERY, Quick Query, INVEST_ID_M1
Column
Title
Width
Return Item
1
Investigator
200
AE_CASES. INVEST _ID_M1
2
Last Name
200
3
First name
200
4
City
300
5
Country
100
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.
Oracle Clinical configuration A-7
Specific Oracle lookups
Record group definition 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, ' COL3,
DD-MON-YYYY') A.REPORTED_SEX
FROM
COL4
PATIENT_POSITIONS@ORACLIN
A,
CLINICAL_STUDY_VERSIONS@ORACLIN
B,
STUDY_SITE_PATIENT_POSITIONS@ORACLIN C, STUDY_SITES@ORACLIN WHERE B.STUDY =
D
: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_ID = B.CLINICAL_STUDY_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
Field LOV Mappings The following tables contain the field LOV mappings for the OCL_PATIENTS record group. Each table title lists the form, window, and item. Table A–16
E_ENTRY, Demographics, PATIENT_ID
Column
Title
Width
Return Item
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
Column
Title
Width
Return Item
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
A-8 Oracle Adverse Event Reporting System Administrator’s Guide
Oracle Clinical reconciliation views
Table A–18
Q_QUERY, Demographics, CENTER_ID
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID
2
City
300
3
Country
100
Table A–19
Q_QUERY, Case Login, CENTER _ID_M2
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M
2
City
300
3
Country
100
Table A–20
Q_QUERY, Quick Query, CENTER _ID_M1
Column
Title
Width
Return Item
1
Center
200
AE_CASES.CENTER_ID_M1
2
City
300
3
Country
100
Oracle Clinical reconciliation views Oracle 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.
Oracle Clinical configuration A-9
Oracle Clinical reconciliation views
A-10 Oracle Adverse Event Reporting System Administrator’s Guide
Related Documents
9i And 10g Difference
July 2020 7
9i To 10g Upgradation
December 2019 17
Upgrade Doc From 9i To 10g
November 2019 6
9i And 9j Tests
October 2019 3