| Oracle® Argus Safety English Administrator's Guide Release 8.0 E54654-02 |
|
 Previous |
This chapter provides best practices for features such as eVAERS and E2B (R3), the administrator of a multi-tenant environment best practice information.
Implement the following best practices in eVAERS:
It is recommended to configure a Reporting Destination with the following settings to enable reports to be sent in eVAERS format:
Message profile to be selected as 'CBER eVAERS V1.0 MESSAGE TEMPLATE'' (standard profile for eVAERS)
Acknowledge profile to be selected with any of the standard E2B (R2) acknowledgement templates
When eVAERS profile is selected, Message type is automatically set as XML and 'Maximum # of reports to include in the msg' is set to 1 as batching of report in an xml is not supported in this release
When vaccine reporting is being done using VAERS for Regulatory reporting and eVAERS for Pilot testing, then it is recommended to create a new Reporting Destination for eVAERS.
When vaccine reporting is switched over from the VAERS to eVAERS, then it is recommended to configure eVAERS to the Reporting Destination that was used for sending VAERS report.
The default export logic is not provided for the some of eVAERS data elements in this release.
Companies can send data for such data elements using customization as per the steps defined below:
Step 1: Define UDF Field
User Defined Fields can be used as per the following table, and users can input data in those fields from the Case Form UI:
| eVAERS Data Element | Description of Data Element | UDF in UI | UDF Type | Length as per eVAERS Specification | Comments |
|---|---|---|---|---|---|
| patientprefix | Patient Prefix | Patient > Patient Information | Text | 50 | |
| patientfax | Patient FAX | Patient > Patient Information | Text | 18 | |
| patientemailaddress | Patient Email Address | Patient > Patient Information | Text | 100 | |
| patientrace2 | Patient race 2 | Patient > Patient Information | Number (Drop Down) | 50 | |
| patientethnicitygroup | Patient Ethnicity Group | Patient > Patient Information | Number (Drop Down) | 50 | |
| parentprefix | Parent Prefix | Patient > Patient Information | Text | 50 | |
| parentgivename | Parent First Name | Patient > Patient Information | Text | 35 | |
| parentmiddlename | Parent Middle Name | Patient > Patient Information | Text | 15 | |
| parentrace1 | Parent race 1 | Patient > Patient Information | Number (Drop Down) | 50 | |
| parentrace2 | Parent race 2 | Patient > Patient Information | Number (Drop Down) | 50 | |
| parentethicitygroup | Parent Ethnicity code | Patient > Patient Information | Number (Drop Down) | 50 | |
| hospitalname | Hospital Name | Events > Event Information | Text | 200 | Field length of 200 characters cannot be accommodated using a UDF, hence a maximum of 100 characters can be supported. |
| hospitalcity | Hospital City | Events > Event Information | Text | 35 | |
| hospitalstate | Hospital State | Events > Event Information | Text | 40 | |
| vaccadmintitle | Title | Vaccine | Text | 50 | It is not recommended to custom map this data element as vaccineadministration block will be repeatable block in the next release |
| vaccadminfname | First Name | Vaccine | Text | 35 | It is not recommended to custom map this data element as vaccineadministration block will be repeatable block in the next release |
| vaccadminmname | Middle Name | Vaccine | Text | 15 | It is not recommended to custom map this data element as vaccineadministration block will be repeatable block in the next release |
| vaccfacilityfax | Facility Fax Number | Vaccine | Text | 18 | It is not recommended to custom map this data element as vaccineadministration block will be repeatable block in the next release |
| vaccfacilityemailaddress | Facility Email Address | Vaccine | Text | 100 | It is not recommended to custom map this data element as vaccineadministration block will be repeatable block in the next release |
| respphysiciantitle | Title | Vaccine | Text | 50 | It is not recommended to custom map this data element as responsiblephysician block will be repeatable block in the next release |
| respphysicianfname | First Name | Vaccine | Text | 35 | It is not recommended to custom map this data element as responsiblephysician block will be repeatable block in the next release |
| respphysicianmname | Middle Name | Vaccine | Text | 15 | It is not recommended to custom map this data element as responsiblephysician block will be repeatable block in the next release |
| phyfacilityfax | Facility Fax Number | Vaccine | Text | 18 | It is not recommended to custom map this data element as responsiblephysician block will be repeatable block in the next release |
| phyfacilityemailaddress | Email Address | Vaccine | Text | 100 | It is not recommended to custom map this data element as responsiblephysician block will be repeatable block in the next release |
| vaccfacilitymilind | Military Site Indicator | Products > Product Vaccine | Number (Drop Down) | 50 | |
| patmilstatus | Patient Military Status | N/A | Number (Drop Down) | 10 | It is not recommended to custom map this data element as this data element will be moved to Patient block in the next release |
| spprodcategory | FDA Specialized Product Category | Products > Product Vaccine | Number (Drop Down) | 100 |
Since the length of the standard UDF Text field is 100 characters, the maximum length of data that can be sent for hospital name data element is 100 characters. The system will be enhanced to capture hospital name data through a standard field and this limitation will be taken care in a future release.
If the length of a data element is less than 100 characters as per eVAERS guidelines and if data is entered upto 100 characters, then system displays error while generating eVAERS report, hence it is recommended to enter by considering the length specified in the 'Length as per eVAERS specification' column of the above table.
Step 2: Provide custom export logic for the required data element
eVAERS standard profile can be copied to create a copy of custom profile and SQL for the required data element can be modified to map the data element to the corresponding UDF.
Step 3: Configure a Reporting Destination with the Custom eVAERS profile
The custom eVAERS profile created in Step 2 to be specified in the Reporting Destination that is identified for sending eVAERS reports.
When vaccine reporting is being done using VAERS for Regulatory reporting and eVAERS for Pilot testing, then it is recommended to create a new Reporting Rules for eVAERS.
When vaccine reporting is switched over from the VAERS to eVAERS, then it is recommended to configure eVAERS to a new Reporting Rule and to de-activate the rule for VAERS report.
It is recommended to configure Codelist data using Flexible Data Re-categorization codelist to ensure legacy Vaccine data is properly represented in eVAERS report.
The values allowed for some fields in eVAERS is slightly different from VAERS report, hence it is recommended to 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.
| Codelist List Value | NCI_CODE |
|---|---|
| Vaccine Provider | C102430 |
| Patient/Parent | C16960 or C42709 |
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 upgrade to 8.0 release, it is recommended to 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 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 upgrade to 8.0 release, it is recommended to 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 Funds codelist provides separate options for Others and Unknown. However prior version of the application had factory data as 'Other/Unknown' in LM_PURCHASED_WITH table. If customers have cases with 'Other/Unknown' data then it is recommended to customize the mapping of the data element <vaccpurchased> to consider the existing 'Other/Unknown' as 'Other' or 'Unknown'.
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, it is recommended to update the NCI codes for these codelist values as per NCI_CODE column.
| Codelist List Value | NCI_CODE |
|---|---|
| Private Doctor's Office/Hospital | C16988 or C16696 |
| Public Health Clinic/Hospital | C51282 or C16696 |
| Military Clinic/Hospital | C51282 or C114861 or C16696 or any other appropriate NCI_CODE |
FDA requires the use of a prefix to determine the application type associated with suspect products. For licensed vaccines, include the appropriate acronym "BLA" "STN" or "PLA" followed by the primary six-digit number. Hence, it is recommended to update the newly added column in Business configuration > Products and Licenses > License > Application type with appropriate license types.
This section describes optional scripts for data migration to new fields.
Illness at the time of Vaccination data is used in 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 'Illlness at Vac' is transmitted in data elements illnessatvaccination and Illnessatvaccinationmeddraversion respectively.
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, then this data can be copied to Case Form > Patient > Other Relevant History by executing the optional upgrade scripts providing along with this release. It is recommended to keep this data in ORH and Vaccine tab in sync so that same data is presented in VAERS and eVAERS report.
Emergency Room Visit data is used in 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.
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, then this data can be copied to Case Form > Event > Emergency Room Visit by executing the optional upgrade scripts providing along with this release. It is recommended to keep this data in Event tab and Vaccine tab in sync so that same data is presented in VAERS and eVAERS report.
eVAERS report transmits LLT code and MedDRA version data from Case Form > Product > Vaccine > Prior Adverse Event. VAERS report continues to print the verbatim text entered for Adverse Event in box 21 as per existing functionality.
It is recommended that customers manually encode the Adverse Events in Case Form > Product > Vaccine > Prior Adverse Event using Encode button so that required information is populated in eVAERS report.
E2B check feature is used to validate the case against E2B profiles and E2B check report provides a list of validations that are failing which enables user to correct case data prior to actual report generation.
In this release, E2B check will not validate the case against eVAERS profilem hence it is recommended to perform E2B check on the case prior to eVAERS report generation and check for validation messages that are listed for E2B (R3) profile, as the data elements in E2B (R3) profile is a subset of data elements in eVAERS profile.
This section lists the ways to configure E2B (R3) Reports.
It is recommended to create separate Reporting Destination for E2B (R3) profile. The configuration of Reporting Destination for E2B (R3) is same as that of E2B (R2) profile except for the following changes:
Message profile to be selected as 'ICH-ICSR V3.0 MESSAGE TEMPLATE' (standard profile for E2B (R3)) or any customized E2B (R3) Profile.
Acknlowledge profile to be selected with any of the standard E2B (R2) acknowledgement templates.
When E2B (R3) profile is selected, Message type is automatically set as XML and 'Maximum # of reports to include in the msg' is set to 1 as batching of report in an xml is not supported in this release.
The system verifies the file format of the incoming xml files and will either proceed with import or reject files based on the type of files that are expected by the Reporting Destination, i.e. if a E2B (R3) file is received for a Reporting Destination configured with E2B (R2) profile, the file will be rejected and vice versa.
The Common Profile switch 'Default viewing format of the E2B report (used with Interchange)' and 'Default DTD ' are used for both E2B (R2) and E2B (R3) reports.
The following are the recommended Common Profile Switch settings:
Default view switch can be set to SGML or Decoded View as these views are common for E2B (R2) and E2B (R3) reports
Default DTD can be configured with only profile so either E2B (R2) or E2B (R3) report can be generated using Draft tool button
When E2B (R3) report is received from a Partner or an Agency, the report is downgraded from E2B (R3) to E2B (R2) format using BFC xslts and then imported to Argus database using the profile that is set in the Internal Common Profile Switch 'E2B_R3_IMPORT_PROFILE'. By default, the switch is set to 'ICH-ICSR V2.1 MESSAGE TEMPLATE'. An Acknowledgement is generated by the system in E2B (R2) format using Ack profile configured for that Reporting Destination. The acknowledgment is then upgraded to E2B (R3) format and sent to the sender of the report.
H.1 (Case Narrative) data in E2B (R3) report can be upto 100,000 characters, while importing E2B (R3) report with H.1 data element having 100,000 characters, the downgraded reports retains the complete data and it is imported to Narrative field. Please refer to the Backwards and Forwards Compatibility Recommendations in the 3_ICH_ICSR_BFC_Specification_v2.00_clean.pdf provided by ICH.
ICSR Attachments can be sent in E2B (R3) and eVAERS reports. Reporting Destination for E2B (R3) / eVAERS needs to be configured for sending attachments by marking 'Transmit E2B Attachments' and selecting the 'Attachment classification' that are required to be sent as inline attachments in these reports.
Attachments within E2B (R3) and eVAERS reports are encoded using B64 format.
For E2B (R3) reports, attachments are compressed in the format specified in the Internal Common Internal Profile switch 'ZIPSTREAM_COMPRESSION_ALGORITHM'. DF (Deflate) is the default compression algorithm used for compressing attachments; other options supported are GZ and ZL.
Attachments file size are not checked for E2B (R3) reports during report generation or transmission, hence it is recommended for the users to review the size of the attachments that will be included in E2B (R3) report prior to Report generation.
For eVAERS reports, the following Common profile switches with default settings allows the file types that can be added as attachment and overall size of eVAERS report:
File attachments allowed for eVAERS for determining the appropriate file type that can be included as inline attachments. Default value of this switch is pdf,jpeg,jpg,bmp, png,gif,tif,tiff,rtf, txt,xls,xlsx,doc, docx,wpd as per file format recommended in eVAERS guidelines.
Allowed file size for eVAERS (in MB) for determining the maximum file size (inclusive of attachment data and Case data) of eVAERS report and default value of this switch is 20 MB.
As per eVAERS guidelines, attachments sent in the previously submitted reports should not be sent again in the follow-up or Amendment reports. In this release, check to verify if the attachments were sent in previous version is not built. Hence we recommend users to select the Attachment classification that does not qualify for eVAERS reporting in the follow-up revision of the case so that it is not sent again or alternate method would be to customize the mapping logic for the data elements C.4.r.2 and C.1.6.1.r.2.
When to create Amendments?
If an Initial / Follow-up eVAERS / E2B (R3) reports are submitted to a Reporting Destination/Agency and then if there is a request from Agency to send the attachments, amendments can be created by unlocking the case as significant follow-up and ticking the 'Amendment' checkbox in Case Form > General Tab > Follow-up section and provide the reason for creating Amendments.
Users can include Attachments and provide the details of the attachments in Case Summary.
Auto-scheduling of Amendment Report
Auto-scheduling will then schedule Amendment reports for the Reporting Destination configured for eVAERS / E2B (R3). Follow-up reports are scheduled for Non E2B, E2B (R2) reports if the case satisfies Reporting Rules configured for those reports. These reports are not capable to handle Amendments hence Follow-up reports are scheduled.
Manual Scheduling of Amendment Report
Amendment reports for eVAERS / E2B (R3) can be manually scheduling using 'Scheduling New Expedited Report' dialog. Users can select the Aware date pertaining to the Amendment and schedule an eVAERS / E2B (R3) report. Aware date pertaining to an Amendment can be identified by text ' (A)' appended to the Aware date. It is recommended to have only one amendment for an Aware date, else it may be difficult to identify the latest amendment from Aware date drop down in the 'Scheduling New Expedited Report' dialog.
If a user manually schedules Non E2B or E2B (R2) reports for an Amendment Aware date, then system schedules follow-up report if there is a previously submitted report of the same report type to the same agency, else will schedule an Initial report.
Other Recommendations
It is not recommended to create Amendments for minor Case Form changes as Amendments are meant for significant changes without new aware dates. Capability to allow users to create Amendments for Non-significant changes will be provided in Future releases based on inputs from Agencies and Customers.
Amendments can be created only when there is a previously submitted eVAERS / E2B (R3) report.
This section lists the the best practices to follow in a multi-tenant environment.
Single Sign-on needs to be enabled to have the capability to switch client context and to open the Argus Safety application from the Global Worklists/Application Access Portlet. If SSO is enabled, then it becomes mandatory for a user to be configured as an LDAP user in all the enterprises where the data displays on the screen/portlet.
It is expected that the 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.
For ESM Mapping Utility and EOSU Tool which are client-server applications and do not have a mechanism to specify the Enterprise ID, 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.
Set up appropriate Portal user and user group privileges to restrict access to Portlets and the Global Homepage. It is recommended that you configure the out-of-the-box Portlets so these (specified below) are accessible to all multi-tenant users who need to access data across multiple enterprises, except the ones specifically recommended for administrators.
Global Worklist - New
Global Worklist - Open
Global Worklist - Action Items
Global Worklist - Contacts
Global Enterprise Management: Recommended for Administrators
Global User Management: Recommended for Administrators
Application Access Portlet
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.
In order to apply updates to the "Synchronizable" fields to all the enterprises in the system, you should maintain some administrative users with the Console'Access Management 'Groups' Menus 'Console: Access Management: User menu access enabled for all enterprises in the system.
When a user is copied from one enterprise to another, it is expected that you have set up the appropriate site and the usergroups in the target enterprise. Otherwise the user-association with fail with the appropriate error message.
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.
It is expected that you create and choose the appropriate Enterprises with generic configuration data which can be used as source for copying the configuration data for creation of a new enterprises. Following is a list of items that the you are recommended to ensure that the values being copied from the source enterprise are appropriate for the newly created enterprise:
Advanced Conditions used within any configuration item
Reporting Destination Code List ' Company identifier field values
System Numbering and LAM System Numbering Formats
ESM Mapping Utility ' Setup INI File Setup ' Service DB Setup ' Outgoing and Incoming folders for each Agency.
Common Profile Switches
MedWatch Configuration
Documentum configuration
Lot Number Web Service Configuration
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
Path for New Case from Image: Argus Console ' Common Profile Switches ' Case Processing ' Default Network directory for scanned images
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
The following is the list of items that are segregated by enterprises but the CRO is recommended to maintain consistent across all enterprises:
Common Profile Switches ' Argus Insight URL
Common Profile Switches ' Argus Safety Load Balancer Server
System Configuration ' Enabled Modules
Following is the list of items that are common for all enterprises
MedDRA and WHO Web Services
Common Profile Switches ' Security ' LDAP ' Enable/disable LDAP
Common Profile Switches ' Security ' LDAP ' LDAP Server configuration
Common Profile Switches ' Security ' Enable/disable SSO
Common Profile Switches ' Security ' SSO Header Configuration
Common Profile Switches ' Case Processing ' Where to store temporary case information during data entry
Common Profile Switches ' Case Processing 'Auto Archiving ' The database job and its frequency - "Execution Period (in Days)"
Default Enterprise
The common profile switches (related to SSO, LDAP, Auto Archiving job & frequencyand Temporary Case Data Storage) which are common for all enterprises will only be displayed, updated and audit logged in DEFAULT enterprise. This is because any update to global level profile switches impacts all enterprises and is controlled. Also, such an update will also require propagation of the audit log to all other enterprises where the current user may not even exist or may not have proper access.
Make sure that all the AG Service users (login user id) in all the databases that are to be merged into single database are in sync with the DEFAULT ENTERPRISE. If there are AG Service users in other enterprises which do not exist in the DEFAULT ENTERPRISE, then you can either rename their login user IDs to map them to existing AG Service users in the DEFAULT ENTERPRISE or delete them. If extra users are found in other enterprises during multi-tenant database migration, then they will be marked disabled and you will not be enable them later.
Make sure that all the event & indication and who-drug encoding dictionaries used in Argus Console ' System Configuration 'Common Profile Switches 'Case Form Configuration 'Auto Encoding, Dictionary and Central Encoding section and Argus Console ' Business Configuration 'Studies 'Enable Study Specific Encoding 'Auto Encoding dialog, in all databases that are to be merged into single database are already loaded in the target database with the same name. This is required to enable the automatic linking of dictionaries configured in the separate databases to the already existing dictionaries present in the target database during the database merge script/process.
E2B Outgoing and Incoming folders is configured again in ESM Mapping Utility because various folders for different transmission methods are now merged as one pair of folders for all transmission methods. Now these are saved into database rather than the ESM Service INI file.
Document Type field value from ESM Service configuration and AG Service configuration tool is now be configured again into Argus Console ' Common Profile Switches ' Documentum configuration as these fields are now moved to Argus Console.
Make sure that all the event & indication and who-drug encoding dictionaries used in Argus Console ' System Configuration 'Common Profile Switches 'Case Form Configuration 'Auto Encoding, Dictionary and Central Encoding section and Argus Console ' Business Configuration 'Studies 'Enable Study Specific Encoding 'Auto Encoding dialog, in the newly migrated enterprises are linked properly to the global dictionaries already present in the target database. This is required to correct any dictionary configuration linking that could not be done automatically by the database merge script due to mismatch in dictionary names in the source and target databases.
Existing single-tenant as well as multi-tenant Documentum users upgrading to AS 7.0 release, and are migrating/keeping all the documents in the Documentum server, is also add additional attributes- "enterprise_id" and "enterprise_short_name" and populate these appropriately for all their documents that are to be accessed by Argus Safety in Documentum server.
Existing single-tenant as well as multi-tenant users which are upgrading to AS 7.0 release, and have configured "Use Logged in User's Username/Password" for Argus Console ' System Configuration ' Common Profile Switches ' Document Management for Case Attachments will switch to Common Username/Password for Documentum login if not already configured for E2B, Expedited and Periodic Reports.
MedDRA and WHO Webservices: As MedDRA and WHO webservice is common for each enterprise, it will use only single version for encoding events and drugs. However, as these web services use the dictionaries configured in Argus Console ' System Configuration 'Common Profile Switches 'Case Form Configuration 'Auto Encoding, Dictionary and Central Encoding section for the respective enterprises for populating dictionary id and dictionary version information for the encoded items, configure these dictionaries as same across all enterprises.
|
 Copyright © 2015,2016, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|