10 Best Practices

10.1.4.1 eMDR Specific Codelist Updates

Occupation

The Occupation codelist is provided with Factory data along with NCI_Codes. If Companies already have entered data in this codelist and if this data has been used in the Device cases prior to upgrading to the 8.x release, Oracle recommends you do the following:

• Update the NCI codes for the existing data in Occupation codelist using Flexible Data Re-categorization codelist.

• Set Display to No, for the new factory data provided in Occupation codelist using Standard Codelist .

10.1.4.2 eVAERS Specific Codelist Updates

Since the values allowed for few fields in eVAERS are different from VAERS report, Oracle recommends you configure the existing codelist values with appropriate NCI_CODE in the Flexible Data Re-categorization Codelist so that appropriate data is sent in eVAERS reports.

Relation to Patient

Relation codelist is now provided with additional Factory data along with NCI_Codes as per CBER guidelines on eVAERS. If there are legacy cases with data that is similar to the values provided in the table, Oracle recommends you update the NCI codes for these codelist values as per NCI_CODE column.

Anatomical Location

Anatomical Locations codelist is now provided with Factory data along with NCI_Codes. If Companies already have entered data in this codelist and if this data has been used in the Vaccine cases prior to upgrading to the 8.0 release, Oracle recommends you do the following:

• Update the NCI codes for the existing data in Anatomical Location codelist using Flexible Data Re-categorization codelist.

• Set Display to No, for the new factory data provided in Codelist -> Anatomical Location.

Ethnicity

Ethnicity codelist is now provided with Factory data along with NCI_Codes. If Companies already have entered data in this codelist and if this data has been used in the Vaccine cases prior to upgrading to the 8.0 release, Oracle recommends you do the following:

• Update the NCI codes for the existing data in Ethnicity codelist using Flexible Data Re-categorization codelist.

• Set Display to No, for the new factory data provided in codelist -> Ethnicity.

Vaccination Facility

Vaccination Facility codelist provides distinct options for facility types. However prior version of application had factory data as follows in LM_VACCINATED_AT table. If there are legacy cases with any data same as the value provided in the below table, Oracle recommends you update the NCI codes for these codelist values as per NCI_CODE column.

10.1.6.1 Setting up the Application Type in Business Configuration -> Products and Licenses (eVAERS specific)

FDA requires the use of a prefix to determine the application type associated with suspect products. For licensed vaccines, you must include the appropriate acronym BLA, STN, or PLA followed by the primary six-digit number. Therefore, Oracle recommends you update the newly added column in Business Configuration->  Products and Licenses->  License-> Application Type with appropriate license types.

10.1.6.2 Configuring PMDA Specific License Parameters

Configure the following License level parameters that will be used to auto-populate the respective configured values in the Case Form:

Status category of new drug: Use this drop-down list to set the status category of the new drug as per the allowed values from the License category codelist. This configured value is used to auto populate the Case Form -> Analysis -> PMDA -> General -> Category of New Drug.The user can modify the auto populated value in the Case Form.

Risk category of OTC drug: Use this drop-down list to set the Risk category of OTC Drug as per the allowed values from newly added Risk category codelist depending on the value for OTC Product checkbox. This configured value auto populates the Case Form -> Analysis -> PMDA -> General -> Route of acquiring OTC drugs. The user can modify the auto populated value in the Case Form.

10.1.6.3 Configuring PMDA E2B (R3) Specific Study Parameter

Configure the appropriate Notification number for existing studies in the Study Configuration J pop-up. The value configured here is expected to be transmitted in J2.13.r.1 (Notification Number) tag of PMDA E2B (R3) report.

10.1.7.1 PMDA E2B (R3) Specific Switches

Some switch based application behaviors may impact the PMDA E2B (R3) report directly or indirectly.Oracle recommends you configure the appropriate switch value as per company specific business needs:

• Profile Switch under Common Profile -> Argus J

  1. On Adding/Updating the Case form -> Events -> Description as Reported by an English user, auto populate Description as Reported on the Japanese side with:

     Option 1: English Verbatim (Default)

     Option 2: Japanese PT (From Meddra J)

     Based on the value configured for the above switch, the application auto populates the user entered English verbatim or the Japanese PT in the Japanese verbatim.

  2. Allow user to update the Reason for Downgrade/Nullification report and Comments for start date of reporting timeframe after the case is locked (globally and locally locked):

     Option 1: Yes (default)

     Option 2: No

     Based on the value configured for the above profile switch, Reason for Downgrade/Nullification report and Comments for start date of reporting timeframe text areas are made available for edit even after the case lock.

  3. Default viewing format of the PMDA E2B R3 report (used with Interchange-J)

     Option 1: XML

     Option 2: Decoded (Default)

     Option 3: HL7

     The default view for E2B Viewer for PMDA E2B R3 report can be configured using the above profile switch.

• Profile Switch under Common Profile -> Case Processing -> Dictionary Browser

  1. Allow User to Add Non-Current Meddra Terms for:

     Option 1: Case irrespective of Country of Incidence

     Option 2: Case where Country of Incidence is other than Japan (Default)

     This profile switch value is used to control the application behavior to allow the user to add the Non-current LLT (J) term to Case Forms.

  2. On change of LLT Term Sync English and Japan LLTs, irrespective of the currency:

     Option 1: Yes

     Option 2: No (Default)

     This profile switch value is used to set the application behavior to synchronize the LLT term when the user updates the LLT.

10.1.8.1 eVAERS specific

Illness at the time of Vaccination

Illness at the time of Vaccination data is used in the eVAERS report and this data is captured in Case Form -> Patient ->  Other Relevant History ->  Condition Type = Illness at Vac. LLT code and MedDRA version of the ORH record with Condition Type as Illness at Vac is transmitted in data elements illnessatvaccination and Illnessatvaccinationmeddraversion respectively.

The VAERS report continues to map Illness at the time of Vaccination with the corresponding field in Vaccine tab.

If Illness at time of Vaccination in Vaccine tab has data in legacy cases, this data can be copied to Case Form -> Patient ->  Other Relevant History by executing the optional upgrade scripts providing along with this release. Oracle recommends you keep this data in ORH and Vaccine tab in sync so that same data is presented in VAERS and eVAERS report.

Emergency Room visit

Emergency Room Visit data is used in the eVAERS report and this data is captured in Case Form -> Event -> Emergency Room Visit (checkbox). If this checkbox is checked, then seriousnesservisit data element is transmitted as true. If this checkbox is unchecked, then null flavor NI is transmitted.

The VAERS report continues to map Emergency Room visit data with the field Required ER visit in Vaccine tab.

If Required ER visit checkbox is ticked in Vaccine tab in legacy cases, this data can be copied to Case Form -> Event->  Emergency Room visit by executing the optional upgrade scripts providing along with this release. Oracle recommends you keep this data in Event tab and Vaccine tab in sync so that same data is presented in VAERS and eVAERS report.

Prior Adverse Event

The VAERS report transmits LLT code and MedDRA version data from Case Form->  Patient ->  Other Relevant History. Upgrade scripts are provided to copy data from Case Form ->  Product ->  Vaccine ->  Prior Adverse Event (where Person type=Patient ) to Case Form->  Patient ->  Other Relevant History.

The VAERS report continues to print the verbatim text entered for Adverse Event in box 21 from Case Form ->  Product ->  Vaccine ->  Prior Adverse Event as per existing functionality.

Oracle recommends that customers enter Prior Adverse Event experience by Patient in Case Form ->  Patient ->  Other Relevant History so that required information is populated in the eVAERS report and if the VAERS report must be sent, the same data can be entered in Case Form ->  Product ->  Vaccine ->  Prior Adverse Event.

Admin By and Responsible Physician

The Vaccine Administration Section in Products > Vaccine has been re-organized and several new fields have been included to be compliant with CBER eVAERS Guidance.

Upgrade scripts are provided to copy data from Admin By (CASE_VACC_VAERS.ADMIN_BY) to Best Doctor Physician Last Name ( ), if Admin By is blank, the data from Responsible Physician CASE_VACC_VAERS.PHYSICIAN is copied.

Based on company requirements, the upgrade logic can be altered to consider Responsible Physician data first instead of Admin By.

10.1.8.2 eMDR Specific

Device Age and Unit

The Device Age and Unit fields are provided in Products -> Device tab. Upgrade scripts are provided to copy data from Device Age (approx) to Device Age and Unit fields by using the following logic. Oracle recommends customers review this logic and make necessary changes based on the format in which Device Age was entered in Device Age (approx) field.

1. Device Age is derived from CASE_PROD_DEVICES.DEVICE_AGE by considering the initial numeric value of the Device Age field value.

2. Unit is derived from CASE_PROD_DEVICES.DEVICE_AGE by considering later portion of Device Age field value.

   a. Unit is populated as Hours, if the later portion of CASE_PROD_DEVICES.DEVICE_AGE text is Hour or Hours or Hr irrespective of upper/lower case used.

   b. Unit is populated as Days, if the later portion of CASE_PROD_DEVICES.DEVICE_AGE is Day or Days or Da irrespective of the upper/lower case used.

   c. Unit is populated as Month, if the later portion of CASE_PROD_DEVICES.DEVICE_AGE is Month or Months or Mo irrespective of the upper/lower case used.

   d. Unit is populated as Year, if the later portion of CASE_PROD_DEVICES.DEVICE_AGE is Year or Years or Yr irrespective of the upper/lower case used.

Location where Event Occurred

The Location where event occurred field is changed to a type ahead field in Case Form -> Analysis -> MedWatch Info tab.

Previously, Location Where Event Occurred was captured using multiple checkboxes representing different locations. As per typical business use case, the event occurrence is likely to happen only in one location.

Upgrade scripts are provided to copy data from the following fields with matching Codelist ID from the Location event occurred codelist. If data is present in more than 1 field, the data is not copied in the upgraded database and the upgrade log indicates that users need to manually select appropriate data for this field as the prior version had multiple options marked.

• CASE_MEDWATCH_DATA.LOC_HOSP

• CASE_MEDWATCH_DATA.LOC_HOME

• CASE_MEDWATCH_DATA.LOC_NH

• CASE_MEDWATCH_DATA.LOC_OTF

• CASE_MEDWATCH_DATA.LOC_ODF

• CASE_MEDWATCH_DATA.LOC_ASF

• CASE_MEDWATCH_DATA.LOC_OTHER

10.5.1.1 Accessing Argus Safety Directly via URL

It is expected that you will pass the internal Enterprise ID as a URL parameter for the Argus Safety application to open with the appropriate Enterprise context. If Enterprise ID is not passed, the user is validated against the default enterprise.

Because the EOSU Tool is a client-server application and does not have a mechanism to specify the Enterprise ID, it will always validate users against the default enterprise. Hence, users that are expected to login into these applications are configured with appropriate access/roles within default enterprise. For this reason, "Active" checkbox for the default enterprise is always marked checked and disabled in Global Enterprise Management screen.

10.5.2.1 Global Worklists Columns

The system allows flexibility to hide some of the fields/columns in the Global Worklist Portlets through the Global Worklist grid/menu XML(s) which resides on the Web Server(s). It is advisable to hide only those fields/columns which are not updated nor referred by any Worklist context menu actions.

10.5.2.2 Global User Management

Global User Management is intended to configure users across multiple enterprises. When user configuration changes need to affect only a specific enterprise, it needs to be done from the Argus Safety Console > User Management screen for that enterprise.

The Browser displays a left hand pane that lists the existing users (distinct users based on Login User ID) in the system, in a tree view. The tree displays users from the enterprise partitions for which the user has access.

Figure 10-1 Argus Safety Console Browser

Local users can locally lock a case for which local Japan data entry/assessment is complete, triggering the scheduling and/or generation of the applicable local reports. Similarly, they can locally unlock the case after a local lock is applied and modify the data. To grant the privilege to locally lock or unlock a case to a local user, you can use the Allow Local Locking option from the Argus Console > Access Management > Users section. The checkbox is unchecked by default.

10.5.2.3 Global Enterprises

From the Global Enterprise Management tab, you can:

• Add a new enterprise.

• Define new enterprise attributes.

• Copy configuration from an existing enterprise.

• Associate users to the new enterprise.

10.5.2.4 User-Enterprise Association

To associate existing users from one enterprise to other enterprises:

1. Select an enterprise from Copy User Attributes From.

   Note:

   The selected enterprise is used to set the attribute values for the user in the new enterprise to which the user is being associated. The attribute values for the already associated enterprises remain the same.

2. Add an Available Enterprise or Add All available enterprises.

3. Select Save.

   Note:

   During Save, all the user attributes are copied from the Enterprise selected in the Copy User Attributes From to all the newly associated Enterprises.

4. To print the user details of the current user or all the users, select Current User or All Users and click Print.

When a user is copied from one enterprise to another, it is expected that you have set up the appropriate site and the user groups in the target enterprise. Otherwise the user-association with fail with the appropriate error message.

10.5.2.5 New User Creation/Association

Argus Console allows same UserID to be used to create different users across multiple enterprises. It is recommended that this feature is only be used if users are not expected to be shared across enterprises. Otherwise, if users are expected to be shared across multiple enterprises, then same UserID will not be used to create different users across different enterprises. Instead of that, a user created in one enterprise is associated to other enterprises through Global User Management.

10.5.2.6 Synchronizable User Attributes

The purpose of the Synchronizable User Attributes section is to allow you to apply updates to user attributes displayed in this section, and keep them in sync across all enterprises.

The users that are listed to be administered in this screen are restricted by the following rules:

• Admin users, System users and users for which the Service User is checked in Console are not listed.

• Only the users from the enterprises for which you have access to the Console User management screen, i.e. you should have access to all of the following in those enterprises:

  • Console User Management screen ' Application Access field ' Console checkbox is checked.

  • Console Group Management screen ' Menus section ' Console, Access Management and User radio options are set to enabled at least for one user group in the respective enterprise partition.

  • Is not marked as "Account Disabled".

When you select the Synchronize User Attributes tab, the left hand pane displays a list of enterprises to which the user being administered belongs to. The right hand pane displays a list of Synchronizable user attributes in a grid.

The value of the Synchronizable fields can be modified for a specific enterprise so that these attributes can be different for that enterprise as compared other enterprises.

10.5.2.7 Inactivating an Enterprise

It is recommended that you first archive all the cases belonging to the Enterprise before inactivating the Enterprise.

10.5.5.1 Data Segregation by Module

The following table describes how each module in the Oracle Health Sciences Safety suite provides data segregation in a multi-tenant environment.

10.5.5.2 Data Segregation by Enterprise

Following is the list of items that are segregated by enterprises. It is recommended that you configure distinct values across enterprises to ensure proper data segregation across enterprises.

• Literature Intake folder: Argus Console ' Common Profile Switches ' Argus J ' Shared Path for the Literature Intake

• Case Intake folder: Argus Console ' Code List ' User Sites ' Intake File Path

• E2B Incoming Folder: ESM Mapping Utility ' Setup INI File Setup ' Service DB Setup ' Incoming Folder

• Site Printers: Argus Console ' Code List ' User Sites ' Site Printers ' Path

10.5.5.3 Data Segregation impact on system-level configuration items

The following table specifies some specific system-level configuration items which are configured through Argus Console. It specifies the impact on these configuration items due to data segregation design for multi-tenant installations and also specifies the recommendations for customers on these items.