The chapter provides best practices for setting up the Argus Safety application to use the ICH E2B(R3), eVAERS, eMDR, and PMDA E2B(R3) reports. It contains the following sections:
HL7 reports include the ICH E2B(R3), eVAERS, eMDR, 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 | E2B(R2) Acknowledgement Profile |
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 |
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 |
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:
|
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
When an E2B (R3) report is received from a Partner or an Agency, the report is downgraded from E2B (R3) to E2B (R2) format using BFC xsl 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 the E2B (R3) format and sent to the person who initially sent 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 the Narrative field.
For more information, refer to the Backward and Forward Compatibility Recommendations in the 3_ICH_ICSR_BFC_Specification_v2.00_clean.pdf provided by ICH.
Import for eVAERS, eMDR and PMDA E2B(R3) is currently not provided.
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) and PMDA E2B(R3) reports, attachments are compressed in the format as specified in the l Common Internal Profile switch.
ICH E2B (R3) uses 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), eVAERS, eMDR, PMDA(R3) Profile).
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
Auto-scheduling then schedules Amendment reports for the Reporting Destination configured for eVAERS / E2B (R3). Follow-up reports are scheduled for Non E2B and E2B (R2) reports if the case satisfies the reporting rules configured for those reports. These reports are not capable of handling Amendments and so Follow-up reports are scheduled.
Manual Scheduling of Amendment Reports
Amendment reports for eVAERS / E2B (R3) can be manually scheduled 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
Oracle recommends you do not create Amendments for minor Case Form changes as Amendments are meant for significant changes without new aware dates.
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 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.