HL7 reports include the ICH E2B(R3), eVAERS, eMDR, EMA E2B(R3), and PMDA E2B(R3) reports built using HL7 v.3.0. This section contains the following topics:
The Reporting Destination must be configured with the appropriate profile based on the report type to be sent to the Agency:
Configuring Profiles for Message and Acknowledgement
Message and Acknowledge profile must be selected as follows for different report types:
Agency | Message Profile | Acknowledgement Profile |
---|---|---|
CBER | CBER eVAERS V1.0 MESSAGE TEMPLATE | - |
CDRH | CDRH EMDR V1.0 MESSAGE TEMPLATE | Disabled for eMDR Profile |
PMDA | ICH-ICSR V3.0 MESSAGE TEMPLATE - PMDA | PMDA E2B(R2) Acknowledgement Profile |
ICH | ICH-ICSR V3.0 MESSAGE TEMPLATE | E2B(R2) Acknowledgement Profile |
EMA | ICH-ICSR V3.0 MESSAGE TEMPLATE | E2B(R3) Acknowledgement Profile |
Path for Incoming and Outgoing Messages
The Path for Incoming and Outgoing Messages or Acknowledgements must be specified in:
Codelist -> Reporting Destination -> EDI tab -> Incoming folder
Codelist -> Reporting Destination -> EDI tab -> Outgoing folder
Attachment and Report File Size Configuration
The attachment file and overall file size of the reports are checked for HL7 reports during report generation or transmission. The file size and attachment size limit can be configured using the parameters in the Reporting Destination Code list.
The recommended size for various report types are:
Report Type | Allowed attachment file size (in MB) | Allowed report size (in MB |
eVAERS | 15 MB | 20 MB |
eMDR | 15 MB | 50 MB |
ICH E2B R3 | 15 MB | 20 MB |
PMDA R3 | N.A. | AS1: 10 MB
AS2: 50 MB |
EMA | 15 MB | 20 MB |
For more information on changes required in the file types, refer to the Console guide for the Common profile switch for the file types allowed for the report forms.
ICSR Report Submission Date Configurations
The existing profile switch based system level ICSR submission date options have now been moved to reporting destination level for all ICSR submissions. Hence, set the appropriate value for the respective destinations for both R2 and R3 reports.
Note:
Refer to Attachments in HL7 reports for settings to be made in Reporting Destination.
Oracle recommends that you configure the existing Reporting Destination that was used for sending MedWatch/VAERS with the eMDR/eVAERS profile.
When reporting is switched from the current PMDA E2B (R2) to PMDA E2B (R3), the follow-up report numbering sequence remains intact (including downgrade and nullification report over the previous PMDA E2B R2).The same is applicable when reports are switched from EMA E2B(R2) to EMA E2B(R3).
Perform the following steps to customize profiles:
Creating a Custom Profile:
Standard profiles must be copied to modify mappings or add new elements. You can copy a profile using the Copy button in Interchange Mapping.
Adding extension elements:
If a new element is required in a profile due to a change in regulations, the extension element can be added to the Custom Profile. The extension element is created using the Insert statement in the CFG_E2B table.
Providing custom export logic for the required data element:
SQL for the required data element can be modified in the custom profile using the Interchange Mapping.
Updating XSL files
If the xpath of the element must be changed due to a change in regulations, the corresponding XSL must be altered. The location of XSL files is:
{ArgusInstallPath(FromArgus.ini)} \ Argus.NET\CommonWebUIComponent \HL7\XSLT\AS\
Refer E2B(R3) Extensibility guide for guidelines on updating XSL files.
Configuring a Reporting Destination with the Custom profile:
The custom profile created in step1 must be specified to the required Reporting Destination.
A new ICSR validation framework has been implemented for E2B (R3) based ICSR reports. This provides a robust framework to enhance the ICSR generation validation capabilities to reflect the process by which they are executed by the regulatory authorities.
Currently, only PMDA E2B (R3) is using the new framework for validations by default. All required factory data validation have been provided for PMDA E2B R3 template profile only.
If you want to enable the new framework for other R3 based ICSR profiles (ICH and eVAERS), load/add the required validations using the UI and update the back-end profile level flag (CFG_PROFILE.APPLY_CONF_RULE=1).
Oracle recommends you configure Codelist data using the Flexible Data Re-categorization codelist to ensure legacy Vaccine data is properly represented in reports.
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 .
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.
Codelist List Value | NCI_CODE |
Vaccine Provider | C102430 |
Patient/Parent | C16960 or C42709 |
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.
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 |
License Category
Data for the License category codelist has been synchronized as per the PMDA E2B (R3) regulation. The E2B (R2) codes have been mapped to the appropriate values with the following exceptions:
Update the appropriate E2B (R2) codes for the newly added items to the codelist.
Study Development Phase (Development Phase)
Data for Study Development Phase codelist has been synchronized as per the PMDA E2B (R3) regulation. The E2B (R2) codes have been mapped to the appropriate values with the following exceptions:
Update the appropriate E2B (R2) codes for the newly added items to the codelist.
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.
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.
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
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.
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.
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
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.
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.
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.
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.
Device Age is derived from CASE_PROD_DEVICES.DEVICE_AGE by considering the initial numeric value of the Device Age field value.
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
ICSR Attachments can be sent in ICH E2B (R3), eVAERS, eMDR, and PMDA E2B(R3) reports. The Reporting Destination must be configured for sending attachments by marking Transmit E2B Attachments and selecting the Attachment classification that is required to be sent as an inline attachments in these reports.
Attachments are encoded using the B64 format.
Compression Format
For ICH E2B (R3), EMA E2B(R3), and PMDA E2B(R3) reports, attachments are compressed in the format as specified in the l Common Internal Profile switch.
ICH E2B (R3) and EMA E2B(R3) reports use the internal common profile switch ZIPSTREAM_COMPRESSION_ALGORITHM. DF (Deflate) is the default compression algorithm used for compressing attachments; other options supported are GZ and ZL.
PMDA E2B(R3) reports uses the common Profile switch Compression algorithm for file attachments in PMDA E2B R3. DF (Deflate) is the default compression algorithm used for compressing attachments; the other option supported is GZ IP.
eMDR and eVAERS profiles do not require compression as per guidelines from CDRH and CBER respectively.
File Formats
For more information on file formats supported for Attachments, refer to the following sections.
Configuring Common Profile Switches -> For configuring file types for the Report Types.
Attachment Size
For more information on Attachment size validation, refer to the following sections.
Attachment and report file size configuration: Configuring Reporting Destination for ICH E2B(R3), EMA E2B(R3), eVAERS, eMDR, and PMDA(R3) profiles.
When to create Amendments?
If Initial / Follow-up eVAERS / E2B (R3) reports are submitted to a Reporting Destination/Agency and then there is a request from the Agency to send 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 providing the reason for creating Amendments.
Users can include Attachments and provide the details of the attachments in the Case Summary.
Auto-scheduling of Amendment Report
Amendment reports are auto-scheduled for cases with Significant Amendments only for the Reporting Destination configured with an eVAERS / E2B (R3) Profile.
Follow-up reports are auto-scheduled for cases with Significant Amendments for the Reporting Destinations that are configured with Non E2B and E2B (R2) reports.
Manual Scheduling of Amendment Reports
Amendment reports for eVAERS / E2B (R3) can be manually scheduled for Significant Amendments or Non Significant Amendments using the 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. Oracle recommends you have only one amendment for an Aware date, else it may be difficult to identify the latest amendment from the Aware date drop-down list in the Scheduling New Expedited Report dialog.
If 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
Amendments can be created only when there exists a previously submitted eVAERS / E2B (R3) report.
Null flavor data is not sent in eMDR in absence of clear guidance on the exact null flavor allowed for the individual data elements.
Null Flavor can be entered for Date and Text fields as per the ICH E2B(R3) Implementation Guidelines.
EMA, CBER, PMDA have minor differences in the allowed Null Flavors for various data elements.
Oracle recommends you customize the fields with appropriate Null Flavor sets based on reporting needs.
New Null Flavor sets can be created using Flexible data re-categorization.
For text fields, Null Flavors must be entered for English and Japanese fields separately by manually selecting them from the NF drop-down list.
Null flavors can be selected for Codelist fields by selecting key values such as MASKED, UNKNOWN and so on from the typeahead/drop-down fields.
During Report generation, mapping logic for the data elements (that support Null flavors) identifies these keywords as Null flavors and populates required information in the HL7 report.
Validation is done to check for only allowed Null flavor if Case data is missing. Error messages are displayed if incorrect Null flavors are used for a data element or when both Case Form data and Null flavors do not have the mandatory data elements.
This section lists 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 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.
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.
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.
Note:
Your access is restricted depending on your access to this Portlet at the Portal server level.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.
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.
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.
To associate existing users from one enterprise to other enterprises:
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.Add an Available Enterprise or Add All available enterprises.
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.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.
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.
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.
Note:
If User Name and Email address fields are updated in Argus Safety Console for a user which belongs to multiple enterprises, an error displays.If you make changes to the data on one of these tabs and attempts to move away from this current tab without saving the changes, then the warning message "You have made changes to the existing item, if you press OK, changes will be lost." displays. Click OK to ignore changes. Click Cancel to stay on the current tab.
Click Add New Enterprise.
Enter information about your Enterprise in the required fields.
Click Next.
From Copy Configuration Data Source, select an Enterprise to use as a template for your new Enterprise.
Tip:
You can makes changes to the configuration once the enterprise has been set up.Click Setup.
Click Finish.
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 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
Case Processing - Default Network Directory for Scanned Images
Note:
The Default Network Directory for Scanned Images is partitioned by enterprise/client. You can define separate image folders to accept company-specific image files for the New Case from Image functionality.Multi-tenancy allows an organization to use a single database for many clients, which reduces the amount of hardware needed for an implementation. Fewer patches and dictionary upgrades are required, which decreases the resources necessary to support an implementation. This also allows administrators to use standard configurations, such as code lists, workflow steps and user/new client setup.
The entire Argus Safety application and all of its components and data are partitioned by Enterprise ID. The Enterprise ID is a unique identifier for a customer's client and contract. The appropriate context of the Enterprise ID selected by the user that the user has access to, is set by the system and operates within the partition of this context.
The following table describes how each module in the Oracle Health Sciences Safety suite provides data segregation in a multi-tenant environment.
Note:
It is not recommended that you open the Argus Safety application for multiple enterprises at the same time. Close the Argus Safety application for the previous enterprise before opening it for the next enterprise to avoid data issues.It is recommended that you use the Application Access portlet to open the Argus Safety application for different enterprises, as it takes care of closing the previous enterprise before opening the new one.
Module | Cross Enterprise | Accessed Via Portal | Notes |
---|---|---|---|
Global Worklists | Yes | Yes | Displays data from across multiple enterprises. |
Global User Management | Yes | Yes | Displays data from across multiple enterprises. |
Global Enterprise Management. | Yes | Yes | Displays data from across multiple enterprises. |
Applications Access | Yes | Yes | Displays Application Access options from across multiple enterprises. |
Argus Safety | No | No | Displays data for one enterprise at a time to the logged-in user based on the selected enterprise. |
Argus Console | No | No | Displays data only for the enterprise for which Argus Safety was opened by the user. |
Argus Affiliate | No | No | Displays data for one enterprise at a time to the logged-in user, based on the selected enterprise. |
Argus Unblinding | No | No | Displays data for one enterprise at a time to the logged-in user, based on the selected enterprise. |
ESM Mapping Utility | No | No | Displays data for one enterprise at a time to the logged-in user, based on the selected enterprise.
However, the screens related to ESM Service Configuration display data related to all the active enterprises, irrespective of the user access rights to those enterprises. |
Argus Interchange Service | Yes | No | ESM Service process data from all the enterprises, as it is a background service. |
ESM Service Configuration | Yes | No | As ESM Service is common across all the enterprises, hence its configuration tool is also common. |
Argus Safety Service | Yes | No | Argus Safety Service processes data from all the enterprises as it is a background service. |
AG Service Configuration Tool | Yes | No | As AG Service is common across all the enterprises, hence its configuration tool is also common. |
MedDRA Re-code Tool | Yes | No | Allows the option to perform recoding of MedDRA terms across the enterprises. |
MedDRA Dictionary Load | Yes | No | Single instance/version of the loaded MedDRA dictionary is available for all the enterprises. |
MedDRA/WHO Web Services | Yes | No | These web services remain common to be used across all the enterprises. Their configuration is maintained in a common XML file on the web server(s). |
J Drug Dictionary | Yes | No | Single instance/version of the loaded J Drug dictionary are available for all enterprises. |
Case Intake | No | No | Case Intake messages for separate enterprises are segregated and loaded into appropriate enterprise partitions. |
Literature Intake | No | No | Literature Case Intake data for separate enterprises are segregated and loaded into appropriate enterprise partitions. |
New Case from Image | No | No | Scanned Image folder paths for separate enterprises are segregated and loaded into correct enterprise partitions. |
PSL | No | No | The PSL interface segregates the incoming requests for each enterprise partition. |
DLP | No | No | Partitions the case revisions by enterprises. |
TMS Integration | No | No | TMS integration for single-pharma installations only. |
Argus Dossier | No | No | As this module is linked to Periodic Reports, hence it partitions the periodic reports data by enterprise. |
Global Worklists | Yes | Yes | Displays data from across multiple enterprises. |
Global User Management | Yes | Yes | Displays data from across multiple enterprises. |
Global Enterprise Management. | Yes | Yes | Displays data from across multiple enterprises. |
Applications Access | Yes | Yes | Displays Application Access options from across multiple enterprises. |
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
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
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.
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.
Configuration Item | Application Design | Recommendation for Customers | Configuration Item |
---|---|---|---|
Enable/Disable MedDRA/WHO Web Service Encoding | System keeps it segregated for each enterprise.
However, the underlying web service used for MedDRA/WHO is common for all the enterprises as their configurations are maintained in common XML file on the web server(s). |
None | Enable/Disable MedDRA/WHO Web Service Encoding |
Lot Number Web Service configuration | System keeps it segregated for each enterprise. | As this is related to the product, Oracle recommends you keep it specific for each enterprise. | Lot Number Web Service configuration |
Documentum Configuration | System keeps it segregated for each enterprise. | All parameters except for Cabinet Name are expected to be maintained as same for different enterprises. | Documentum Configuration |
Enable/disable LDAP
& LDAP Server configuration |
This will be maintained by application as common for all enterprises. | None | Enable/disable LDAP
& LDAP Server configuration |
Enabled Modules | The system keeps it segregated for each enterprise. | None | Enabled Modules |
Enable/disable SSO
& SSO Header Configuration |
This will be maintained by application as common for all enterprises. | None | Enable/disable SSO
& SSO Header Configuration |
Argus Insight URL | System keeps it segregated for each enterprise. | It is expected to be maintained same for across all enterprises by the customer. | Argus Insight URL |
Argus Safety Load Balancer Server | System keeps it segregated for each enterprise. | It is expected to be maintained same for across all enterprises by the customer. | Argus Safety Load Balancer Server |
User Information | System keeps it segregated for each enterprise. | For multi-tenant installations, user attributes can be synchronized for all the enterprises through Global User Management.
However, user attributes can also be updated for a specific enterprise through Console as well. |
User Information |
Default Enterprise | System keeps it segregated for each enterprise. | This is a new internal common profile switch that marks an enterprise as the Default enterprise. This is set during the time of install. Default enterprise once created during database creation is fixed. This is required to avoid the data synchronization issues that may occur for AG Service users in different enterprises. | Default Enterprise |
SMTP Configuration | System keeps it segregated for each enterprise. | None | SMTP Configuration |
Enable/Disable MedDRA/WHO Web Service Encoding | System keeps it segregated for each enterprise.
However, the underlying web service used for MedDRA/WHO is common for all the enterprises as their configurations are maintained in common XML file on the web server(s). |
None | Enable/Disable MedDRA/WHO Web Service Encoding |
Lot Number Web Service configuration | System keeps it segregated for each enterprise. | As this is related to the product, Oracle recommends you keep it specific for each enterprise. | Lot Number Web Service configuration |
Documentum Configuration | System keeps it segregated for each enterprise. | All parameters except for Cabinet Name are expected to be maintained as same for different enterprises. | Documentum Configuration |
Enable/disable LDAP
& LDAP Server configuration |
This will be maintained by application as common for all enterprises. | None | Enable/disable LDAP
& LDAP Server configuration |
Enabled Modules | The system keeps it segregated for each enterprise. | None | Enabled Modules |
Enable/disable SSO
& SSO Header Configuration |
This will be maintained by application as common for all enterprises. | None | Enable/disable SSO
& SSO Header Configuration |
Argus Insight URL | System keeps it segregated for each enterprise. | It is expected to be maintained same for across all enterprises by the customer. | Argus Insight URL |
Argus Safety Load Balancer Server | System keeps it segregated for each enterprise. | It is expected to be maintained same for across all enterprises by the customer. | Argus Safety Load Balancer Server |
User Information | System keeps it segregated for each enterprise. | For multi-tenant installations, user attributes can be synchronized for all the enterprises through Global User Management.
However, user attributes can also be updated for a specific enterprise through Console as well. |
User Information |
Default Enterprise | System keeps it segregated for each enterprise. | This is a new internal common profile switch that marks an enterprise as the Default enterprise. This is set during the time of install. Default enterprise once created during database creation is fixed. This is required to avoid the data synchronization issues that may occur for AG Service users in different enterprises. | Default Enterprise |
SMTP Configuration | System keeps it segregated for each enterprise. | None | SMTP Configuration |
Enable/Disable MedDRA/WHO Web Service Encoding | System keeps it segregated for each enterprise.
However, the underlying web service used for MedDRA/WHO is common for all the enterprises as their configurations are maintained in common XML file on the web server(s). |
None | Enable/Disable MedDRA/WHO Web Service Encoding |
Lot Number Web Service configuration | System keeps it segregated for each enterprise. | As this is related to the product, Oracle recommends you keep it specific for each enterprise. | Lot Number Web Service configuration |
Documentum Configuration | System keeps it segregated for each enterprise. | All parameters except for Cabinet Name are expected to be maintained as same for different enterprises. | Documentum Configuration |
Enable/disable LDAP
& LDAP Server configuration |
This will be maintained by application as common for all enterprises. | None | Enable/disable LDAP
& LDAP Server configuration |
Enabled Modules | The system keeps it segregated for each enterprise. | None | Enabled Modules |
Enable/disable SSO
& SSO Header Configuration |
This will be maintained by application as common for all enterprises. | None | Enable/disable SSO
& SSO Header Configuration |
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.
You can define which applications are enabled for a selected enterprise from the Argus Safety Console >User Management > Application 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.