Argus Safety Instance Database Schemas The Argus Safety instance requires you to create database schemas. The Argus schema and the Interchange Service schema are required for all systems. The other schemas you create are MedDRA or WHO.
MedDRA-J Browser, free download. MedDRA-J Browser: Society of Japanese Pharmacopoeia. MedDRA Introductory Guide Version 14.0 ii March 2011 MSSO-DI-6003-14.0.0 Notice to Reader. The Introductory Guide is intended for use in conjunction with the MedDRA Browser, available with each MedDRA subscription. This Log Data may include information such as your computer's Internet Protocol ('IP') address, browser type, browser version, the pages of our Site that you visit, the time and date of your visit, the time spent on those pages and other statistics.
Argus Schema: Use the Argus Safety Schema Creation Tool to create this database schema. This is a required schema. Interchange Service Schema: Use the Argus Safety Schema Creation Tool to create this database schema.
This is a required schema. MedDRA Schema: You must create this schema if MedDRA is to be enabled. This schema is created by the MedDRA Loader Tool when MedDRA is loaded to the new database tables. WHO Schema: You must create this schema if WHO is to be enabled. This schema is created by the WHO Loader Tool when WHO is loaded to the new database tables. GMT Offset Calculation For column level description, refer to the Oracle Argus DBA Guide. Verify that the value stored in the TABLE is accurate for GMTDIFF and other columns related to Day Light Saving.
Be aware of the following:. Argus is using function gssutil.gmtoffset to derive the GMT OFFSET which impacts the calculation of GMT date and time.
Use the following SQL queries to verify the GMT offset returned by the database function:. Query to get the current GMT Time offset. Query to get the current Timestamp and GMT Timestamp. Daylight Savings Time.
Assume that Daylight Savings Time starts on First Sunday of April at 2:00 AM and it ends on Last Sunday of October at 2:00 AM. Query to get GMT Time Difference just before the starting of Day Light Saving.
![Meddra Browser Free Download Meddra Browser Free Download](http://slideplayer.com/6253411/21/images/34/CTCAE+%E2%80%98Other%2C+specify%E2%80%99+and+MedDRA.jpg)
Query to get GMT Time Difference One Second After Day Light Savings started. Query to get GMT Time Difference just before the End of Day Light Saving. Query to get GMT Time Difference just After Day Light Savings ended. Note: If other DBA user used instead of SYSTEM then change SYSTEM to the name of DBA user. Define userdba=SYSTEM GRANT EXECUTE ON SYS.UTLFILE TO XDB; GRANT EXECUTE ON SYS.DBMSSCHEDULER TO &userdba. WITH GRANT OPTION; GRANT EXECUTE ON SYS.DBMSOBFUSCATIONTOOLKIT TO &userdba.
WITH GRANT OPTION; GRANT EXECUTE ON SYS.UTLFILE TO &userdba. WITH GRANT OPTION; GRANT EXECUTE ON SYS.DBMSRANDOM TO &userdba. WITH GRANT OPTION; GRANT SELECT ON SYS.ALLSOURCE TO &userdba. WITH GRANT OPTION; GRANT EXECUTE on SYS.DBMSRLS TO &userdba. WITH GRANT OPTION.
Note: You must ensure to disable the UAC in order to run the schema creation tool. Before installing the Schema Creation Tool on a server, verify that an Oracle client with Administrator option is installed on the server.
When Argus Safety Setup opens the Argus Safety Solution Components dialog box: from the screen and click Next. Select the Schema Creation Tool. Click Next.
The system begins the installation procedure and displays the Setup Status screen. The system displays installation progress. When the system displays the Setup Completed screen:. Click Finish. When the system copies the required files to the system and displays the following message:. Click OK to reboot the system.
Note: Refer to the chapter to create the Cryptographic key before creating the new schema. Before creating the schema, verify that:.
A blank Oracle database instance is available. A SYSTEM user account is available. The Oracle database is available from the machine where the schema creation tool is installed Use the following procedure to create the schema. Open the schema creation tool. Click Create Schema. When the system displays the Oracle Database Connect dialog box, enter the Password associated with the system user and the Database. Enter the password associated with the system user in the Password field and the database name in the Database field.
When the system displays the Argus Safety Schema Creation Options dialog box:. Enter the user name in the VPD Admin Schema Owner field. Enter the user's password in the VPD Admin Schema Owner Password field. Reenter the user's password in the Reenter Password field. When the system displays the New User dialog box:.
Enter the user name in the New User Name field. Enter the user's password in the New User Password field.
Reenter the user's password in the Reenter Password field. Verify that the Default Tablespace and Temporary Tablespace values are correct. When the system displays the Argus Safety Schema Creation Options dialog box, repeat Steps 3 and 4 until you have created all the users. When the system displays the Argus Safety Schema Creation Options dialog box:.
Click New Role to create the following roles as appropriate:. Argus Role. Interchange Role.
When the system displays the New Role dialog box:. Type the role name in the New Role field. When the system redisplays the Argus Safety Schema Creation Options dialog box:. Locate the Argus Safety Schema Owner drop-down list and select the Argus Schema Owner you created. Locate the Schema Options and select the appropriate Database Size and the Time Zone. Locate the Oracle Licensing Option and select the applicable licensing option.
Select the appropriate Argus Role from the Argus Safety Role drop-down list. Locate Argus Safety Grantees and select the appropriate Argus Login account. Locate the Interchange Support section and do the following:. Select the Interchange Schema Owner from the drop-down list.
Select the Interchange Role from the drop-down list. Select the Interchange Login User from the drop-down list. Enter password for the ARGUSUSER user. Select an Application Type from the following two radio buttons:.
Single Tenant - Selecting this option allows the database to only support a single tenant. The options to create multiple tenants in the safety system is diabled. Multi-Tenant - Selecting this option allows the database to support multiple tenants. Users are able to create multiple tenants using the Global Enterprise setup screens. Select the Default Enterprise from the following:.
Enterprise Name. Enterprise Short Name. Click Generate. If the Tablespace Creation dialog box displays, you may create new tablespaces or use existing tablespaces as follows:. Under Complete Path and Datafile, enter the complete path (including the filename) under which the data file is located on the database server. If the data file does not exist, the system automatically creates it. It will automatically be created.
If the data file exists, the system prompts you to use the current data file. Select Yes in the dialog. Note: The Tablespace Creation dialog appears if the Database Size was selected as Small, Medium, or Large. It will not appear if the database size was selected as Default.
When you have existing tablespaces, you may use them; you are not required to create new ones. The system will not regenerate the tablespaces. If a tablespace already exists the Argus Schema Creation tool will warn you to select Yes to use an existing tablespace. When the system opens the Argus Safety Database Installation dialog box:. Select Pause on error. Select Continue to start the Schema Creation Process. It may take some time to complete the schema creation process.
Loading Factory Data Before loading factory data verify that:. The schema creation tool is installed.
An Oracle database instance is available. A SYSTEM user account has been created To load Factory Data into the Argus Safety database:. Open the schema creation tool. Click Factory Data. When the system opens the Connect to Database dialog box:, enter the Argus Schema Owner Name, Password, and the Database name in the appropriate fields and click OK.
Enter the name of the Argus Schema Owner and the password. When the system opens the Connect to Database dialog box a second time:. Enter the name of the Interchange Schema Owner and the password. Enter the default user passwords for the Admin User and the System User. Verify the passwords for both users in their Password Verify fields. The system loads the factory data into the database and displays the following message: 'Factory Data has been loaded. Please check your factory data folder for 'Log' files.'
. Check the.BAD and.LOG files in the DB Installer FactoryData folder to verify that the factory data loaded without errors. Enabling Oracle Text Once enabled, Oracle Text performs the following functions:. DB Installer checks whether Oracle Text is installed. If not, it displays an error message that 'Oracle Text not installed.
Please install Oracle Text before adding this feature'. Estimates the Tablespace Size Requirements and adjusts as required. Populates existing cases in the Oracle Text duplicate Search Table for indexing. This process can take a few hours. Creates the Oracle Text Index. Creates the PDP job for Delta updates. Updates the CMNPROFILE Key, ORATXTSRCHENABLE, to a value of 1.
Before enabling Oracle Text, there must be enough free space available in the tablespace. If there is not enough free space available, the system displays the following dialog box with the amount of space currently available (in megabytes). Click OK and provide the required free space before enabling Oracle Text. Use the following procedure to enable Oracle Text:.
Open the Schema Creation Tool. Click Oracle Text.
When the system displays the Enable/Disable Oracle Text dialog box:. Click Yes. When the system displays the Enable Oracle Text dialog box, enter the connection parameter in the Argus Database Name field and click Proceed. Enter the database connection parameter.
Enter the Oracle Text Log Directory. Click Proceed to enable Oracle.
View Oracle Text Log. Click Close to exit. Oracle Text is enabled. Click Close to exit. Run the schema validation tool to validate the schema. Disabling Oracle Text After Oracle Text is disabled, the system performs the following functions:.
Updates the CMNPROFILE Key, ORATXTSRCHENABLE, to a value of 0. Deletes the PDP Job. Drops the Oracle Text Index.
Truncates the Duplicate Case Search Table Use the following procedure to disable Oracle Text. Open the Schema Creation Tool. Click Oracle Text. When the system displays the Enable/Disable Oracle Text dialog:.
Click No. When the system displays the Disable Oracle Text dialog box:. Enter the database connection parameter in the Argus Database Name field. Enter the Oracle Text Log Directory. Click Proceed to disable Oracle Text. The system disables Oracle Text.
View Oracle Text Log. Click Close to exit. Loading the MedDRA Dictionary To load the MedDRA dictionary into the database:.
Open the Schema Creation Tool:. Click MedDRA Loader. When the system displays the Oracle Database Connect dialog box, Click OK. Enter the Password associated with the SYSTEM user and the Database name. When the system displays the MedDRA Dictionary Loader dialog box, do the following:.
Select Load to New Tables if a MedDRA dictionary has not been loaded before. Select MedDRA J if you are loading a MedDRA J dictionary. Locate the Tablespace Information section and select the tablespace and index from the drop-down lists. Click Create User to create a new MedDRA user. When the system displays the New MedDRA User dialog box:, enter the appropriate information in the fields and click OK. Enter the name of the user in the New User Name field. Enter the password in the New User Password field.
Reenter the password in the Reenter Password field. When the system redisplays the MedDRA Dictionary Loader dialog box again:. Click Create Role.
When the system displays the New MedDRA Role dialog box:, enter the New Role name and click OK. Enter the new role name in the New Role field. When the system redisplays the MedDRA Dictionary Loader dialog box:, locate the Dictionary to Load section an do the following:.
Select the MedDRA Version to be loaded from the drop-down list. Click Browse to go to the directory where the dictionary files reside and select the appropriate dictionary files. Check the MedDRA Browser checkbox if this dictionary version is being used in the Argus Safety MedDRA Browser.
Click Load. Select the MedDRA version to be loaded from the MedDRA Version drop-down list. The system loads the dictionary and displays the following message.
Note: If loading MedDRA V8 or V8.1, the smqlist.asc and smqcontent.asc files containing SMQ data must be placed in the same folder as the other dictionary files. Open the schema creation tool.
Click MedDRA Loader. When the system displays the Oracle Database Connect dialog box:. Enter the SYSTEM user password in the Password field and the database name in the Database field. When the system displays the MedDRA Dictionary Loader dialog box: locate the Loading Options section and do the following:. Select Overwrite. Select MedDRA J if you are loading a MedDRA J dictionary. Select the tablespace and index from the Tablespace and Index drop-down lists.
Select the user from the User drop-down list. Enter the user password in the Password field; re-enter it in the Verify Password field. Select the appropriate role from the Role drop-down list. Select the version to overwrite from the Current Version to Overwrite drop-down list. Select the MedDRA version to load from the MedDRA Version drop-down list. Click Browse to go to the directory where the dictionary files reside and select the appropriate dictionary files. Click the MedDRA Browser checkbox if the dictionary version is being used in the Argus Safety MedDRA Browser.
Click Load. When the system displays the Oracle Database Connect dialog box: enter the Password associated with the SYSTEM user and the Database name and click OK. Enter the SYSTEM user password in the Password field and the database name in the Database field. When the system finishes overwriting the dictionary, it displays the Dictionary Load dialog box.
Option Point E Argus MedDRA Version to Re-code Select the existing MedDRA version to re-code. Enterprises Select the enterprises to recode. Data Update/View Options Currency determined at LLT Level Only Check one or both of the following options: Process Current Terms (Using Primary SOC Path) Process Non-current Terms (Using Primary SOC Path) Select one of the following options: Update Data (Updates will be made to cases and to the audit log.) View Only (Updates will not be made to cases and to the audit log).
Output Log File Options Select an output log file option and directory path for the log files. Status Displays status. If you find it necessary to recode events, use the following procedure to do so:. Open the schema creation tool. Click MedDRA Loader.
When the system displays the Oracle Database Connect dialog box, enter the Password associated with the SYSTEM user and the Database name. Enter the password for the SYSTEM user in the Password field and the database name in the Database field. When the system displays the MedDRA Dictionary Loader dialog box:. Click Re-Code Events. When the system opens the Event Re-Coding dialog box, do the following:. Select the Enterprise to recode.
Note: If Argus is setup in Single Tenant Mode, you will only have one option here. If you are setup as a Multi-Tenant Database, you can choose which Enterprises to recode. Multiple enterprises can be selected. Select the existing version of MedDRA that needs to be re-coded.
Select a specific version to only recode data coded with that version. Select ”All” to recode all existing coded data regardless of the version it is coded with.
Select either or all of the Process Current Terms, Process Non-Current Terms and/or Update dictionary version checkboxes. Select Update Data if events are to be updated or select View Only if you are interested is just seeing what events will be coded without making the changes. Select the Output File format. Delimited Text. Excel Sheet output. Click on the Execute button to start the recoding process.
When the system displays the Connect to Database dialog box, enter the Schema Owner name, Password, and Database. Enter the schema owner name in the Argus Schema Owner field. Enter the password in the Password field.
Enter the database name in the Database field. The system recodes the following fields from Case Form and Code List. Loading the J Drug Dictionary To load the J Drug dictionary into the database:.
Open the Schema Creation Tool:. Click J Drug Loader. When the system displays the Oracle Database Connect dialog box, Click OK. Enter the Password associated with the SYSTEM user and the Database name. When the system displays the J Drug Dictionary Loader dialog box, do the following:. Select Load to New Tables if a J-Drug dictionary is not loaded before. Locate the Tablespace Information section and select the tablespace and index from the drop-down lists.
Click Create User to create a new J-Drug user. When the system displays the New J-Drug User dialog box:, enter the appropriate information in the fields and click OK.
Enter the name of the user in the New User Name field. Enter the password in the New User Password field. Reenter the password in the Reenter Password field. When the system redisplays the J-Drug Dictionary Loader dialog box again:. Click Create Role. When the system displays the New J-Drug Role dialog box:, enter the New Role name and click OK. Enter the new role name in the New Role field.
When the system redisplays the J-Drug Dictionary Loader dialog box:, locate the Dictionary to Load section an do the following:. Select the J-Drug Version to be loaded from the drop-down list. Click Browse to go to the directory where the dictionary files reside and select the appropriate dictionary files. Check the J-Drug Browser checkbox if this dictionary version is being used in the Argus Safety MedDRA Browser. Click Load. The system loads the dictionary and displays the following message.
Note: If loading MedDRA V8 or V8.1, the smqlist.asc and smqcontent.asc files containing SMQ data must be placed in the same folder as the other dictionary files. Open the schema creation tool. Click MedDRA Loader.
When the system displays the Oracle Database Connect dialog box:. Enter the SYSTEM user password in the Password field and the database name in the Database field. When the system displays the MedDRA Dictionary Loader dialog box: locate the Loading Options section and do the following:.
Select Overwrite. Select MedDRA J if you are loading a MedDRA J dictionary. Select the tablespace and index from the Tablespace and Index drop-down lists. Select the user from the User drop-down list. Enter the user password in the Password field; re-enter it in the Verify Password field. Select the appropriate role from the Role drop-down list.
Select the version to overwrite from the Current Version to Overwrite drop-down list. Select the MedDRA version to load from the MedDRA Version drop-down list. Click Browse to go to the directory where the dictionary files reside and select the appropriate dictionary files. Click the MedDRA Browser checkbox if the dictionary version is being used in the Argus Safety MedDRA Browser. Click Load. When the system displays the Oracle Database Connect dialog box: enter the Password associated with the SYSTEM user and the Database name and click OK.
Enter the SYSTEM user password in the Password field and the database name in the Database field. When the system finishes overwriting the dictionary, it displays the Dictionary Load dialog box.
Option Point E Argus MedDRA Version to Re-code Select the existing MedDRA version to re-code. Enterprises Select the enterprises to recode. Data Update/View Options Currency determined at LLT Level Only Check one or both of the following options: Process Current Terms (Using Primary SOC Path) Process Non-current Terms (Using Primary SOC Path) Select one of the following options: Update Data (Updates will be made to cases and to the audit log.) View Only (Updates will not be made to cases and to the audit log).
Output Log File Options Select an output log file option and directory path for the log files. Status Displays status. If you find it necessary to recode events, use the following procedure to do so:. Open the schema creation tool. Click MedDRA Loader. When the system displays the Oracle Database Connect dialog box, enter the Password associated with the SYSTEM user and the Database name. Enter the password for the SYSTEM user in the Password field and the database name in the Database field.
When the system displays the MedDRA Dictionary Loader dialog box:. Click Re-Code Events. When the system opens the Event Re-Coding dialog box, do the following:.
Select the Enterprise to recode. Note: If Argus is setup in Single Tenant Mode, you will only have one option here. If you are setup as a Multi-Tenant Database, you can choose which Enterprises to recode. Multiple enterprises can be selected.
Select the existing version of MedDRA that needs to be re-coded. Select a specific version to only recode data coded with that version. Select ”All” to recode all existing coded data regardless of the version it is coded with. Select either or all of the Process Current Terms, Process Non-Current Terms and/or Update dictionary version checkboxes. Select Update Data if events are to be updated or select View Only if you are interested is just seeing what events will be coded without making the changes. Select the Output File format.
Delimited Text. Excel Sheet output. Click on the Execute button to start the recoding process. When the system displays the Connect to Database dialog box, enter the Schema Owner name, Password, and Database. Enter the schema owner name in the Argus Schema Owner field. Enter the password in the Password field.
Enter the database name in the Database field. The system recodes the following fields from Case Form and Code List.
Loading the WHO-Drug Dictionary to New Tables Use the following procedure to load WHO-Drug dictionary to new tables:. Launch the schema creation tool:.
Click Who Drug Loader. When the system displays the Oracle Database Connect dialog box:. Enter the SYSTEM password in the Password field. Enter the database name in the Database field.
When the system opens the WHO-Drug Dictionary Loader dialog box do the following:. Click Load New Tables to load the dictionary into a separate schema.
Click Create User to open the New WHO-Drug User dialog box to open the New WHO-Drug User dialog box. Provide the information required to create a new user and click OK. The system reopens the WHO-Drug Dictionary Loader dialog box, click Create Role to open the New WHO-Drug Role dialog box.
In the New WHO-Drug Role dialog box, enter the New Role name and click OK. When the system redisplays the WHO-Drug Dictionary Loader dialog box, locate the Dictionary to Load section and do the following:. In the New WHO-Drug Role dialog box, enter the New Role name and click OK. When the system displays the WHO-Drug Dictionary Loader dialog box with the appropriate information: click Load. When the system displays the Dictionary Load dialog box to indicate that the dictionary has loaded successfully: click OK. Enter the SYSTEM password in the Password field.
Enter the database name in the Database field. Loading the WHO-Drug Dictionary Using the Overwrite Option Use the following procedure to when using the overwrite option to load the WHO-Drug Dictionary:.
Launch the Schema Creation Tool. Click Who Drug Loader. When the system opens the Oracle Database connect dialog box:. Enter the SYSTEM password in the Password field. Enter the database name in the Database field. When the system opens the WHO-Drug Dictionary Loader dialog box, do the following:.
Click Overwrite to overwrite existing dictionary files. Select the dictionary version to load. Click Browse to display the Select Folder dialog box and select the appropriate path and click Select.
Click Load to load the dictionary. View WHO-Drug dictionary log. When the system opens the Oracle Database Connect dialog box, enter the SYSTEM User Password and click OK. Enter the SYSTEM password in the Password field. Enter the database name in the Database field. When the system displays to Dictionary Load dialog to indicate that the dictionary has loaded successfully:.
Click OK. To Load the WHO-Drug Dictionary using the Format C Option Format C is a WHO-Drug dictionary format. For information about this format, go to. To load the WHO-DRUG dictionary using the Format C option:.
Launch the Schema Creation Tool. Click Who Drug Loader. When the system displays the Oracle Database Connect dialog box, enter the SYSTEM Password and Database name.
Enter the SYSTEM password in the Password field. Enter the database name in the Database field. When the system opens the WHO-Drug Dictionary Loader dialog box do the following:. Click Load New Tables to load the dictionary into a separate schema.
Click Create User to open the New WHO-Drug User dialog box When the system opens the New WHO-Drug User dialog box, provide the information required to create a new user and click OK. Select Dictionary Format - Format C. When the system reopens the WHO-Drug Dictionary Loader dialog box:. Click Create Role to open the New WHO-Drug Role dialog box. Provide the information required to create the new role.
When the system redisplays the WHO-Drug Dictionary Loader dialog box:. Select the Dictionary Version to load from the drop-down list. Click Browse to display the Select Folder dialog box and select the appropriate path. When the system displays the WHO-Drug Dictionary Loader dialog box with the appropriate information:. Click Load. When the system opens the Oracle Database Connect dialog box:.
Enter the SYSTEM password in the Password field. Enter the database name in the Database field. When the system displays the Dictionary Load dialog box to indicate that the dictionary has loaded successfully, click OK. Note: If you are creating a fresh Argus Safety database, be sure the factory data is loaded before running the Schema Validation tool.
To validate the Argus Safety database:. Launch the Schema Creation Tool. Click Schema Validation. When the system opens the Connect to Database dialog box:.
Enter the user Password. Enter the name of the database to be validated in the Database field. When the system displays the Schema Validation dialog box:. Validate the values in the fields.
Locate the Validation CTL File section and click Browse to open the Selection Path for CTL File dialog box. Note: If DLP is enabled, the Schema Validation dialog box DLP information as shown in the following illustration. When the system opens the Selection Path for CTL file dialog box:. Click OK. Locate and select the correct folder and CTL file for the database being validated. When the system reopens the Schema Validation dialog box:. Locate the Validation Log Files section.
Click Browse to open the Selection Path for Creating Log Files dialog box. When the system opens the Selection Path for creating Log files dialog box:. Choose the folder where you want the system to create the log files. When the system displays the Schema Validation dialog box with the required entries:.
Click Validate Schema. Click Validate Schema.The system displays the cmd.exe screen to indicate that processing is taking place. Press Enter when the system prompts you to do so. When the system opens the Oracle Sql.Plus window, press Enter. When the system opens another Oracle Sql.Plus:.
Note the path of the log files created during processing. Exit from the Schema Creation Tool. Please check the files for errors.
Enabling DLP Before enabling DLP (Data Lock Point) do the following:. Verify that the Schema Creation Tool is installed. Make sure an Oracle database instance is available. Verify that a SYSTEM user account has been created. Set the jobqueueprocesses parameter in the DLP database to 10. Verify that the globalnames parameter in the Argus and DLP database is set to FALSE.
Verify that both the tnsname parameters in both the Argus and DLP databases are entered in the Argus and DLP database servers. Verify that the database contains extra hard disk space to support DLP. Note: The DBMSRLS package should be granted to a DBA user, only in case of multi-tenant environments. Use the following procedure to enable DLP:. Open the Schema Creation Tool. Click Argus DLP.
When the system displays the Enable/Disable DLP dialog box:. Click Yes.
When the system displays the Enable DLP window, enter the required connection information and click OK. When the system displays the expanded Enable DLP window:. Click New User to create the DLP Stage User in the New User Information dialog box. Enter the required details for the new user and click OK. Enter the user name in the VPD Admin Schema Owner field.
Enter the user's password in the VPD Admin Schema Owner Password field. When the system redisplays the Enable DLP window: click New User again to create the DLP Schema Owner in the New User Information dialog box. Click New User again to create the DLP Schema Owner. Enter the required details for the new DLP Schema Owner and click OK.
The system redisplays the Enable DLP window with the data for the DLP Stage User and the DLP Schema Owner. In the Enable DLP window:.
Locate the Local Folder name to create DLP Process Log and DMP files No Spaces. Click Browse to select a local folder (without spaces) for the temporary path. When the system displays the Select temporary Path window:. Select the appropriate path and click OK. Note: If you are using the Automatic option for extraction method, please skip to Step 16. Use the following parameter file to export the case data: C: Program Files Oracle DBInstaller DLP DLPExportcasedata.par Use the follows sample command and parameter file to export CASE DATA to the Argus Database: connect dbauser/dbauserpassword@Argusdatabase; CREATE DIRECTORY expdir AS 'E: ORADATA TEST DLPDUMP'; GRANT READ, WRITE ON DIRECTORY expdir TO ArgusSchemaowner; EXPDP ArgusSchemaowner/ArgusSchemownerpassword@Argusdatabase PARFILE= E: ORADATA TEST DLPDUMP DLPExportcasedatadp.par; Thoroughly verify LOG file on Oracle errors.
The parameter files DLPExportcasedatadp.par and DLPImportcasedatadp.par are located at C: Program Files Oracle DBInstaller DLP folder. Where: ArgusSchemowner is the Argus Schema Owner in the Argus Database ArgusSchemownerpasword is the Argus Schema Owner password in the Argus Database Argusdatabase is the Argus Database Name DLPSchemowner is the owner of the CLP Schema in the DLP database DLPSchemownerpasword is the password for the DLP Schema Owner in the DLP database DLPdatabase is the DLP database name. Thoroughly check the Log file for Oracle errors. Click OK in the Enable DLP dialog. The system displays the status of the DLP Enable operation in message section of the Enable DLP window. The system displays the following message when DLP execution is complete. Click OK to close the dialog box.
Invoke SQL/PLUS. Connect to DLP database as SYS user and execute the following statements: Connect to DLP database as SYS user. Define userdlp= GRANT EXECUTE ON SYS.DBMSOBFUSCATIONTOOLKIT TO &userdlp.;GRANT EXECUTE ON SYS.DBMSJOB TO &userdlp.;GRANT EXECUTE ON SYS.UTLFILE TO &userdlp.;GRANT EXECUTE ON SYS.DBMSLOB TO &userdlp.;GRANT EXECUTE ON SYS.DBMSRANDOM TO &userdlp.;GRANT SELECT ON SYS.ALLSOURCE TO &userdlp.;REVOKE Execute on sys.DBMSOBFUSCATIONTOOLKIT FROM PUBLIC;REVOKE Execute on sys.DBMSJOB FROM PUBLIC;REVOKE Execute on sys.UTLFILE FROM PUBLIC;REVOKE Execute on sys.DBMSLOB FROM PUBLIC;REVOKE Execute on sys.DBMSRANDOM FROM PUBLIC;REVOKE SELECT on sys.ALLSOURCE FROM PUBLIC;. Invoke SQL/PLUS. Connect to DLP database as DLP user and execute the following script: C: Program Files Oracle DBInstaller Upgrades UPGRADETO70 Common compileobjs.sql. Disabling DLP Since disabling DLP requires restarting both the Argus and DLP databases, verify that no one is logged on to either database before beginning the Disable DLP procedure.
Open the Schema Creation Tool. Click Argus DLP.
When the system displays the Enable/Disable DLP dialog box:. Click No. When the system displays the Disable DLP dialog box:. Enter the required information and click OK.
When the system displays the expanded Disable DLP dialog box:. Click OK to close the dialog box. Click Proceed to start processing. When the system displays the following message, click OK and then click Proceed in the Disable DLP expanded dialog box. Click OK to close the dialog box. Click Proceed to start processing. When the system displays the Disable DLP window:.
Click OK to close the dialog box. The system displays status information regarding the DLP Disable operation in the Disable DLP window. Click Exit. When the Disable DLP operation is complete:. Click Exit. DLP has been disabled.
Upgrading the Argus Safety Database The space requirements for the upgrade are determined by the upgrade script. This requirement is mostly for new objects created during the upgrade. It is a fair estimate of space requirements.
Before starting the upgrade procedure:. Verify that the Oracle TNSNAMES have been configured. To avoid errors during upgrade do either of the following: KEEP DATA FILES AUTOEXTEND ON Monitor free space and add more space if required. Ensure you have a sort area of approximately 100 MB to avoid disk sort. Create one large rollback segment or size 20 GB for LARGE size model.
Keep all other, except SYSTEM, rollback segments off line. Prerequisites After migrating the database from 11.2.0.1 and before starting the 6.0.1 /6.0.1.1/7.0/7.0.0.1 to 7.0.1 upgrade, the following steps need to be followed for Oracle Text:. Run the Schema Creation tool from the 6.0.1 / 6.0.1.1 version of the application (Provided in the zip file for upgrading to 6.0.1/6.0.1.1). Run the Disable Oracle Text and then Enable Oracle Text from Schema Creation Tool. You can refer to the sections below in this Installation Guide on how to disable and enable Oracle Text:.
Disable Oracle Text - see Disabling Oracle Text. Enable Oracle Text - see Enabling Oracle Text Before upgrading the database from 6.0.1/6.0.1.1/7.0/7.0.0.1 to 7.0.1: Connect to ARGUS Safety database as SYS user.
GRANT EXECUTE on SYS.DBMSRLS TO SYSTEM WITH GRANT OPTION; GRANT EXECUTE on SYS.UTLFILE TO XDB. Argus Upgrade from Safety versions prior to AS 6.0.1 / AS 6.0.1.1 / AS 7.0 / AS 7.0.0.1 Argus Safety 7.0.1 provides a direct upgrade from existing Argus Safety (AS) 6.0.1 or AS 6.0.1.1 or AS 7.0 or AS 7.0.0.1 databases to AS 7.0.1. This software also provides support of some previous Argus versions. Please refer to following tables for list of valid source versions. Please refer to following flow diagram high level steps database upgrade to AS 7.0.1.
The following Argus source versions are supported to upgrade the Argus database to AS 7.0.1 as follows. Table 3-1 Upgrade Path Source Version Upgrade path to 7.0.1 Detail Steps using 7.0.1 released software 5.1 5.1 6.0 6.0.1 7.0.1 Extract the following zip file from Argus Safety (AS) 7.0.1 software to a new folder on a workstation where Oracle Client (Administrator option) 11.1.0.7 is installed Previous Database Upgrades Databasereleasedcode60.zip Double click the exe file 'ArgusDBInstall.exe' in DBInstaller folder to start the Safety database upgrade process. Please refer to the AS 6.0 Installation Guide for any details about this upgrade. Once the database upgraded to AS 6.0 refer to section where source version is AS 6.0. 5.1.1 5.1.1 6.0 6.0.1 7.0.1 Extract the following zip file from AS 7.0.1 software to a new folder on a workstation where Oracle Client (Administrator option) 11.1.0.7 is installed. Previous Database Upgrades Databasereleasedcode60.zip Double click the exe file 'ArgusDBInstall.exe' in DBInstaller folder to start the Safety database upgrade process. Please refer to the AS 6.0 Installation Guide for any details about this upgrade.
Once the database upgraded to AS 6.0 refer to section where source version is AS 6.0. 6.0 6.0 6.0.1 7.0.1 Extract the following zip file from AS 7.0.1 software to a new folder on a workstation where Oracle Client (Administrator option) 11.1.0.7 is installed. Previous Database Upgrades Databasereleasedcode601.zip Double click the exe file 'ArgusDBInstall.exe' in DBInstaller folder to start the Safety database upgrade process.
Please refer to the AS 6.0.1 Installation Guide for any details about this upgrade. Argus Safety 7.0.1 supports with Oracle version as 11.2.0.1. If the AS 6.0.1 is with old Oracle version then convert the Argus Safety database from current Oracle version to Oracle 11.2.0.1 Please refer to Oracle Documentation to convert the Oracle database version. Refer to main upgrade (Database Upgrade Procedure (with or Without DLP) from AS 6.0.1 to AS 7.0.1) once the Database is upgraded to AS 6.0.1 with Oracle version 11.2.0.1 6.0.1 6.0.1 7.0.1 Argus Safety 7.0.1 supports with Oracle version as 11.2.0.1. If the AS 6.0.1 is with old Oracle version then convert the Argus Safety database from current Oracle version to Oracle 11.2.0.1 Please refer to Oracle Documentation to convert the Oracle database version. Refer to main upgrade (Database Upgrade Procedure (with or Without DLP) from AS 6.0.1 to AS 7.0) once the Database is upgraded to AS 6.0.1 with Oracle version 11.2.0.1 6.0.1.1 6.0.1.1 7.0.1 Argus Safety 7.0.1 supports with Oracle version as 11.2.0.1.
If the AS 6.0.1.1 is with old Oracle version then convert the Argus Safety database from current Oracle version to Oracle 11.2.0.1 Please refer to Oracle Documentation to convert the Oracle database version. Refer to main upgrade (Database Upgrade Procedure (with or without DLP) from AS 6.0.1.1 to AS 7.0.1) once the Database is upgraded to AS 6.0.1.1 with Oracle version 11.2.0.1 7.0 7.0 7.0.1 Refer to main upgrade.
7.0.0.1 7.0.0.1 7.0.1 Refer to main upgrade. Database Upgrade Procedure (with or without DLP) from AS 6.0.1 to AS 7.0.1 Use the following procedure to upgrade the database. Please note that the Oracle Database Server version should be upgraded to 11.2.0.1 prior to upgrading the database from 6.0.1 to 7.0.1. You may be prompted to press Enter at screens that are not included in the procedure. This does not hinder the upgrade procedure. Where applicable, press Enter to continue with the upgrade process.
Select Start Programs Oracle Schema Creation Tool. When the system opens the Schema Creation Tool:. Click DB Upgrade. When the system opens the Connect to Database dialog box:. Enter the DBA username. Enter the password. Enter the Database name.
Select the version-specific upgrade folder and click OK. Note: The above screen is applicable to upgrades from AS 6.0.1 and 6.0.0.1. Upgrades from AS 7.0 and AS 7.0.0.1 allow selecting the existing VPD User and Application Type, based on the current database type. In the Upgrade Parameters screen of the Argus Safety 7.0.1 release, there are some new options for which data has to be entered.
They are as follows:. Credentials for VPD Admin User - This includes the VPD Admin Schema Owner, Password, and Verify Password.
Application Type - This includes the following two options:. Single Tenant – Select this option if you are upgrading this database and leaving it as a single tenant model. Multi Tenant – Select this option if you are upgrading this database and changing to a multi-tenant model. Default Enterprise Details - This includes the Enterprise Name and Enterprise Short Name.
Note: If DLP is already enabled, the check box will be checked; otherwise it will be unchecked. When the system loads the Tablespace Management window for the Argus database:. Select the tablespace name from the drop-down list corresponding to the description. Click Recalculate Free Space. Verify that the available free space is greater than the amount of required space. If you have increased the freespace, click this button to recalculate the amount of available free space.
Click Next. If DLP is already enabled on the selected Argus DLP database, the system displays the Tablespace Management DLP window. If Argus does not have DLP, this system does not display this screen. Select the appropriate tablespace from the drop-down list. Click Recalculate Free Space.
Verify that the available free space is greater than the amount of required space. Click Next. When the system prompts for confirmation:. Click OK then click Proceed on the main screen. The upgrade start and the system opens the Command prompt window. When the upgrade is complete the system opens the following window:.
Click OK. When the system opens the Database Upgrade Execution window:. Click the log icon to verify any upgrade errors. Click Exit.
When the system opens the Enable Oracle Text window: See section 3.6 'Enabling and Disabling Oracle Text.' . Invoke SQL/PLUS. Connect to DLP database as SYS user and execute the following statements: define userdlp= GRANT EXECUTE ON SYS.DBMSOBFUSCATIONTOOLKIT TO &userdlp.; GRANT EXECUTE ON SYS.DBMSJOB TO &userdlp.; GRANT EXECUTE ON SYS.UTLFILE TO &userdlp.; GRANT EXECUTE ON SYS.DBMSLOB TO &userdlp.; GRANT EXECUTE ON SYS.DBMSRANDOM TO &userdlp.; GRANT SELECT ON SYS.ALLSOURCE TO &userdlp.; GRANT EXECUTE ON DBMSRLS TO WITH GRANT OPTION.
Prerequisites to Running the Merge Import Step. Create a cold backup of the target database before starting the MERGE IMPORT step.
The end user should not use the target database during the import process. There is only one at the time MERGE Import process allowed to run on the Target database. Auto extend should be set on for all Database files in the target database. Sufficient space should be available on the target database server to import the new Enterprise Data. The amount of space depends on the number of cases in source Safety database. Install the Argus 7.0.1 application. Make sure that Oracle Client version is 11.2.0.1.
The Target databases should be Schema Validated at Argus 7.0.1. The target database must be a Multi-tenant database. All source database dictionaries should be available in target Database.
If the dictionary doesn't exist then please install missing dictionaries on Target database. All existing AG service users on the Source Database must exist on the target Database. All source database LDAP configured Server name should be available in target database. Merge Export. Navigate to the following Path from Start Menu: All Programs - Oracle - Merge to Multi-tenant. Click on Export and follow the instructions on the sqlplus screen.
Enter Log File Name to record results. This is the execution log that is created on the client workstation: Log file path:: Program Files Oracle Argus DBInstaller MergetoMultitenant.
Enter TNSNAMES Entry to Connect to the Source SAFETY Database. Enter SYSTEM or DBA user name in source Database. Enter password for DBA user in source Database. Enter SAFETY schema owner name in source Database. Enter password for Safety schema owner in source Database. Enter Interchange schema owner name in Safety Database.
Enter password for Interchange schema owner in source Database. Enter the full directory Path to create the Source Safety database export dump file: This is the Path on the Source Database Server where the Argus Safety Database resides. The Batch file will create an export dump file (SAFETY.DMP) and an export log file (SAFETYEXPORT.LOG) in the Directory.
Make sure that SAFETY.DMP file does not exist prior to the export. Check the database export process log and export step log file for any errors. This is critical step to make sure no errors during export step. Please check following log files:. Log file name entered as parameter 1 during export step execution. Following Oracle Import log files are created on database server. The path is the value entered on ”Enter Directory including full Path to create Source safety database export dump file” during export step: SAFETYEXPORT.log.
Merge Import. Navigate to the following path from Start Menu: All Programs - Oracle - Merge to Multi-tenant.
Click on Import and follow the instructions on the sqlplus screen. Enter Log File Name to record results. This is the execution log will be created on the client workstation.
Log file path:: Program Files Oracle Argus DBInstaller MergetoMultitenant. Enter TNSNAMES Entry to Connect to the Target SAFETY Database.
Enter SYSTEM or DBA user name in target Database. Enter password for DBA user in target Database. Enter VPD schema owner name in target Database. Enter VPD schema owner password in target Database.
Enter SAFETY schema owner name in target Database. Enter password for Safety schema owner in target Database. Enter Interchange schema owner name in target Database. Enter password for Interchange schema owner in target Database. Enter Directory including full Path on target database server where export dmp file copied for import process. This is the Path on the 'Target Database Server' where the Argus Safety Database resides. The Batch file creates an import log files file in the directory mentioned.
Enter the name of new ENTERPRISE. Enter the abbreviation of new ENTERPRISE. Enter SAFETY schema owner name in source Database. Enter Interchange schema owner name in source Database. This Batch files imports the data from the dump file into the target database.
Check the database import process log and import step log file for any errors. This is critical step to make sure no errors during import step. Please check following log files:. Log file name entered as parameter 1 during Import step execution. The following Oracle Import log files are created on database server. The path is the value entered on ”Enter Directory including full Path on target database server where export dmp file copied for import process” during import step. SAFETYIMPORTsafety.log.
SAFETYIMPORTinterchange.log. SAFETYIMPORTSAFETYDUPSEARCHDATA.log. SAFETYIMPORTSAFETYDUPLAMSEARCHDATA.log. Validate the Schema of the Ttget database using Safety Schema Validation tool. Manual Dictionary Synchronization The MERGE process synchronizes the dictionary information based on the dictionary name in the source and target database.
If the source Dictionary name is not available in Target Database then manual synchronization is required. Use the following steps to synchronize the dictionary data manually on the target database:. Log in as Safety schema owner using sqlplus on Target Safety Database. Locate the new ENTERPRISEID value created from import process using the following sql: SELECT VALUE FROM cmnprofileglobal WHERE section = 'DATABASE' AND KEY = 'MERGINGTOMULTITENANT';. Set the context value to new Enterpriseid Exec pkgrls.setcontext('admin','ARGUSSAFETY');. Locate the list of Dictionaries ID's where Dictionary synchronization pending due to missing Dictionaries on Target database. If the following sql results in NO ROWS, then no further action required.
Select dictid From cfgdictionariesenterprise Where enterpriseid = And globaldictid = -1;. Log in as the Safety schema owner using sqlplus on the source safety database. Locate the dictionary name of each Dictionary ID where the Dictionary does not exist on the target database using the following sql: Select name from cfgdictionariesglobal where dictid in (,'ARGUSSAFETY');. Update GLOBALDICTID data in the target database using the following SQL: UPDATE CFGDICTIONARIESENTERPRISE SET GLOBALDICTID = WHERE ENTERPRISEID = AND DICTID = AND GLOBALDICTID =-1. Copy Configuration Tool This tool is intended to provide functionality for copping configuration data from one Argus Safety database to another. The following steps are required to run the tool:.
Validate Schema on the source database using Schema Validation Tool. Make sure that there are no extra or missing objects exist in Schema Validation log file. Messages for extra custom objects created should be ignored. Copy the Copy Configuration Tool utility files recursively from C: Program Files Oracle Argus DBInstaller CopyConfig to the C: CONFIGEXPIMP70 folder.
Export the Source database by running C: CONFIGEXPIMP70 DataExportConfigOnly11g.bat and follow the prompts. Copy ArgusSecureKey.ini (working with Source database) from the. Windows folder and save it with generated source database file. Create a new database using Argus Safety 7.0.1 Schema Creation tool.
Import into Target database by running C: CONFIGEXPIMP70 DataImportConfigOnly11g.bat and follow the prompts. Validate Schema on the target database using Schema Validation Tool. Copy ArgusSecureKey.ini from the source database folder and paste it in the. Windows folder of application server(s) which are intended to be used with the target database.
In case you do not have ArgusSecureKey.ini, follow the steps listed in the section.
Background The Systematic Nomenclature of Medicine Clinical Terms (SNOMED CT) is being advocated as the foundation for encoding clinical documentation. While the electronic medical record is likely to play a critical role in pharmacovigilance - the detection of adverse events due to medications - classification and reporting of Adverse Events is currently based on the Medical Dictionary of Regulatory Activities (MedDRA). Complete and high-quality MedDRA-to-SNOMED CT mappings can therefore facilitate pharmacovigilance. The existing mappings, as determined through the Unified Medical Language System (UMLS), are partial, and record only one-to-one correspondences even though SNOMED CT can be used compositionally. Efforts to map previously unmapped MedDRA concepts would be most productive if focused on concepts that occur frequently in actual adverse event data. We aimed to identify aspects of MedDRA that complicate mapping to SNOMED CT, determine pattern in unmapped high-frequency MedDRA concepts, and to identify types of integration errors in the mapping of MedDRA to UMLS.
Results All but 46 Adverse-Event and 7 Therapeutic-Indications preferred terms could be composed using SNOMED CT concepts: none of these required more than 3 SNOMED CT concepts to compose. We describe the common composition patterns in the paper.
About 30% of both Adverse-Event and Therapeutic-Indications Preferred Terms corresponded to single SNOMED CT concepts: the correspondence was detectable by human inspection but had been missed during the integration process, which had created duplicated concepts in UMLS. Background The Systematic Nomenclature of Medicine Clinical Terms (SNOMED CT) , originally developed by the College of American Pathologists, and now managed by the International Health Terminology Standards Development Organization (IHTSDO) has been repeatedly demonstrated to be the most comprehensive single-source controlled vocabulary with respect to clinical content coverage-.
Consequently, there are efforts at several levels toward making SNOMED CT the basis for encoding of clinical documentation. Adverse events following therapeutic interventions, e.g., pharmaceutical preparations and medical devices, are an important and often preventable, cause of morbidity and mortality in patients. While some Adverse Events are discovered through preclinical testing and clinical trials prior to drug or device approval, the vast majority are discovered during post-marketing safety surveillance simply because of the much larger number of patients who are exposed to the agent over longer periods of time.
With the push towards wider deployment of electronic medical records (EMRs), the EMR is likely to become an increasingly important source of Adverse Event discovery. Several efforts, notably by Carol Friedman's group at Columbia University, have been directed at using natural-language processing (NLP) techniques to determine the feasibility of detecting Adverse Events in clinical text ,. If such efforts prove successful, it may become possible to enable automated or semi-automated Adverse Event detection.
The US Federal Drug Administration's Adverse Events Reporting System (AERS) supports post-marketing surveillance. Reporting to the AERS is voluntary in the US for primary health care providers and others, such as patients, patient relatives, and lawyers. If, however, such individuals have reported a problem to the agent's manufacturer, the latter is legally required to send the report to the FDA. Within the US and internationally, the controlled vocabulary that forms the basis of adverse event reporting, both for post-marketing surveillance as well as for drug agency-regulated clinical trials, is the Medical Dictionary for Regulatory Activities (MedDRA) , developed by the International Conference on Harmonization (ICH). MedDRA includes concepts not only for Adverse Events but also for the therapeutic indications for which the medication/device was employed. The 'Adverse Events' also include errors in prescribing, dispensing and formulation of therapeutic agents, interactions of drugs with other drugs or food, as well as errors that were intercepted before they reached the patient.
Both SNOMED CT and MedDRA are components of the Unified Medical Language System (UMLS) , a compendium ('meta-thesaurus') of a large number of biomedical vocabularies that is distributed by the National Library of Medicine (NLM). If SNOMED CT becomes the basis for encoding clinical documentation, NLP software that assists the encoding of narrative text into SNOMED CT concepts may eventually be bundled ubiquitously with EMR software.
Much NLP software, e.g., GATE and MedLEE is implemented using a pipeline of individual modules, each of which is specialized for a particular sub-task, e.g., section and sentence segmentation, part-of-speech tagging, and named-entity recognition. Rather than creating special-purpose software to generate MedDRA concepts directly from raw clinical text, vendors may find it far simpler computationally to add a MedDRA-generation module at the end of the existing pipeline, to map SNOMED CT concepts into MedDRA equivalents. Such a module will need to utilize a cross-mapping between the SNOMED CT and MedDRA vocabularies. It is therefore essential that these mappings be both comprehensive and of high quality.
In this paper, we describe the issues that were encountered in an exercise aimed at creating a map between MedDRA and SNOMED CT, focusing on high-frequency MedDRA terms for adverse reactions and therapeutic indications in one year's worth of AERS data, which was recorded between July 1, 2008 and April 30, 2009. The motivation for this work is that, as illustrated subsequently, the existing mappings between MedDRA and SNOMED CT are limited and that there are a variety of integration errors in the mapping of MedDRA to UMLS, which is the starting point for our efforts. Our research objectives are stated below:. To identify aspects of MedDRA that complicate the process of mapping MedDRA concepts to SNOMED CT. Through the attempted mapping of high-frequency unmapped MedDRA concepts to SNOMED CT: ○ To categorize patterns that allow composition of MedDRA concepts using SNOMED CT concepts; ○ To identify possible lacunae in SNOMED CT coverage of the adverse event domain; ○ To identify errors where a one-to-one mapping of an unmapped MedDRA concept to a SNOMED CT concept becomes apparent on human inspection, but has not been created in the UMLS. To identify patterns in the integration errors in the mapping of MedDRA to UMLS. An Overview of Terminological Issues related to MedDRA Any attempt to cross-map between SNOMED CT and MedDRA must commence with an understanding of the strengths and limitations of each vocabulary.
SNOMED CT is designed along sound ontological principles. Due to vigorous curation efforts, its content continues to improve with each release. However, the vast size of SNOMED CT - currently around 300 K active concepts - limits the possibility of using all of its content as an 'interface terminology' , i.e., one intended to be employed directly by end-users. The SNOMED CT documentation recommends the creation of subsets to serve special purposes such as coding in clinical sub-domains. For the purpose of Adverse Event capture, MedDRA has the relative advantage of brevity (65 K terms overall) and it is conceivable that the equivalent SNOMED CT concepts would form an 'Adverse Event subset'.
However, MedDRA's design limitations, described in -, which are a consequence of its emphasis on classification, complicate the mapping process and mitigate its usefulness with respect to eventual query and analysis of AERS data at various levels of granularity,. To be fair, MedDRA's creation antedates the current emphasis on integrating ontological principles into controlled vocabulary design, as in the case of SNOMED CT.
Sophisticated controlled vocabulary designs such as implemented in SNOMED CT and UMLS model collections of concepts as graphs with an approximately hierarchical structure. There can be as many levels of hierarchy as are considered appropriate: the number of levels tends to be more for biomedical sub-domains that have been studied for longer periods of time. By contrast, MedDRA content is artificially constrained to a five-level hierarchy: System Organ Classes, High Level Group Terms, High-level Terms, Preferred Terms and Lower Level Terms. The FDA AERS records indications and adverse reactions at the Preferred Term level; there are about 18 K Preferred Terms in MedDRA currently. Individual concepts in a vocabulary should be allowed to descend from more than one parent if necessary: for example, tuberculosis of the spine is both a kind of tuberculosis and a disorder of the spinal column. In MedDRA, this flexibility is artificially limited: Preferred Terms may descend from more than one Higher-level Term, but a given Higher-level Term or Higher-level Group Term may descend from only one SOC.
This leads to difficulties in formulating queries. In MedDRA, there is no semantic consistency in the relationship between a Lower-level term and a Preferred Term. Some Lower-level terms are lexical variants or synonyms of Preferred Terms - e.g., 'cataract, lenticular' is an Lower-level term for the Preferred Term 'cataract' - but others are more specific concepts that should really be coding concepts in their own right - e.g, 'diphtheritic myocarditis' is an Lower-level term related to the Preferred Term 'diphtheria'. Determining the precise semantics of the relationship requires human interpretation. In many cases (such as the cardiac arrhythmias), the Lower-level terms for a given Preferred Term, if looked up in SNOMED CT, may be discovered to have hierarchical relationships among themselves, but these cannot be modeled in MedDRA because a concept 'lower' than an Lower-level term is not permitted. The FDA AERS public data provides Adverse Event details at the Preferred Term level only; finer-level detail that may be clinically relevant, in the case of more specific concepts, is not accessible. MedDRA falls short with respect to several of Cimino's well-known controlled-vocabulary desiderata in addition to the problems of hierarchy discussed above.
○ MedDRA is a non-compositional vocabulary: that is, it is not possible to combine concepts to form new concepts using specified operators. All concepts used in MedDRA are pre-coordinated, i.e., formed by synthesizing a phrase that combines individual concepts, where the semantics of the concept must be determined by human inspection of the terms associated with the concept. A large number of such pre-coordinated concepts combine a laboratory test, e.g., 'bone alkaline phosphatase', with a 'qualifier' attribute that describes the result of the test qualitatively: e.g., normal, abnormal, increased, decreased, positive negative. ○ MedDRA uses semantically ambiguous qualifying phrases such as 'other/not otherwise specified' and 'not elsewhere classified' in many terms. Such concepts are hard to interpret because they are valid only within a single vocabulary, and even here, are based on a criterion of exclusion that is not time-invariant: more categories may subsequently be added, so that the meaning of the concept drifts. Certain pre-coordinated concepts in MedDRA (albeit concepts that do not appear to be used in actual AERS data) are not clinically meaningful. An example category is '(substance) low', where the substance may be lead, cadmium, beryllium, cyanide and several other toxic substances, whose normal level in any tissue should be zero: the concept of a 'low' level is invalid.
(There is a separate concept 'lead decreased' in MedDRA: this concept, which refers implicitly to the presence of a previous measurement, can be meaningful when used to describe the effect of chelation therapy in lead poisoning.). Existing Mappings between MedDRA and SNOMED CT The content of the UMLS's MRCONSO table, which contains mappings of concepts in individual source vocabularies to concepts in the UMLS, can serve as the starting point for mapping vocabularies to each other. The overlap between all of the MedDRA concepts in UMLS and SNOMED CT concepts is around 40%: however, 58% of preferred terms, the most useful part of MedDRA, map to SNOMED CT, as reported by Bodenreider. Our inspection of the MedDRA content that was mapped to UMLS, however, revealed numerous problems that we describe in the Discussion section. In addition, mapping between concepts in a pre-coordinated vocabulary like MedDRA and a vocabulary that allows composition (SNOMED CT) is not guaranteed to be one-to-one. For example, most laboratory-related MedDRA concepts that conflate the test measurement with the qualitative result do not occur in SNOMED CT, but need to be composed by combining the concept of the measurement with a SNOMED CT 'qualifier' concept like 'increased' or 'elevated'. We later consider, in the Discussion, some of the analytical issues that this approach raises.
Source of Adverse-Event Frequency Data Version 11.1 of MedDRA contains 18,209 Preferred Terms. In order to focus our mapping efforts, we assumed that every Preferred Term would be unlikely to occur in actual FDA AERS data, and that a relatively modest proportion of Preferred Terms would account for the majority of actual AERS records. Data for the study was therefore obtained from the FDA AERS download site in order to identify the Preferred Terms that occurred with high frequency. We decided to select those Preferred Terms that collectively accounted for more than 95% of the AERS therapeutic indications and adverse event records: the 95% threshold has been used in other initiatives, such as the NLM's SNOMED CT CORE Subset. Therapeutic Indications Data Adverse Events Data A.
Number of records in data set (each record contains 1 Preferred Term) 850 K 1.19 M B. Unique Preferred Terms in data set 5,540 10,304 C. Number of unique Preferred Terms already mapped to SNOMED CT in UMLS 3864 (69.7%) 6,409 (62.2%) D. Number of unique Preferred Terms accounting for 95% of records ('high-frequency' Preferred Terms) 834 (15.1%), accounting for 60+ records each 2,871 (27.9%), accounting for 32+ records each E.
Number of high frequency Preferred Terms already mapped to SNOMED CT in UMLS 693 (83.1%) 2,226 (77.5%) F. Number needing manual mapping (D-E) 141 645. Mapping of Unmapped Preferred Terms The first author developed a SNOMED CT browser/concept-searcher using Microsoft SQL Server 2008 to host the Jan '09 SNOMED CT content, with a stored-procedure library written using Visual Basic.NET 2008, and a browsing front-end created using Microsoft Access 2003.
The SNOMED CT content was augmented with single-word synonym content from the Unified Medical Language System (i.e., all terms in UMLS for a given SNOMED concept where one of the terms comprises a single lexical token). This software will be made available freely on request to the first author; however, its use is not critical to this work, and alternative concept-searching software, such as the popular CLUE browser, could have been used. The user specifies search terms either by pasting the MedDRA term into a text box, or entering keywords manually. (The software can also run in batch mode: this mode was used to fetch matching candidates into a table for subsequent manual inspection and selection.) Concepts matching one or more words in the search phrase are returned using the well-known 'Term Frequency. Inverse Document Frequency' (TF.IDF) approach for relevance-ranking of search results. The concept-searching process eliminates stop-words from a search phrase (very common words in a language that have minimal search value) using the PubMed stop-word set. The remaining words in the phrase are lemmatized , i.e., conversion to root forms (lemmas) by eliminating variations in tense and person using the program morph, part of the well-known Wordnet thesaurus/software.
Lemmatization can sometimes yield more than one lemma from a given word e.g., the lemma of 'leaves' can be 'leaf' or 'leave', depending on whether 'leaves' is a plural noun or a verb. Lemmatization results in query expansion because the lemmatized words are searched against a lemmatized word index. Further query expansion is performed electronically using a manually created list of Greco-Latin/common-word and other equivalences (e.g., hepatic/liver, gastric/stomach, neoplasm/tumor).
The IDF.TF approach is most appropriate for circumstances where a single concept in SNOMED CT is likely to contain all or most of the words in the MedDRA term. However, a preliminary search of unmapped MedDRA terms had revealed a large number of terms where post-coordination would be necessary, e.g., when a lab test is combined with a single-word qualifier. Here, using the IDF.TF approach to retrieving every SNOMED CT concept that contains at least one word in the search term would return a prohibitive number of concepts. Therefore, the software additionally tries to simultaneously locate SNOMED CT concepts with synonymous terms corresponding to single words in the search phrase.
This is useful for terms such as 'CYTOMEGALOVIRUS CHORIORETINITIS' and 'HAEMATOCRIT ABNORMAL'. Compositional Patterns As expected, many MedDRA Preferred Terms had to be composed using more than one SNOMED CT concept: other than the 'missing concepts' below, none required more than three SNOMED CT concepts to compose.
The following types of composite forms were encountered:;;;; 'prophylaxis'; 'pain'/'inflammation'/'injury'; 'toxicity'. (Strings are denoted in quotes, while unquoted phrases refer to a concept category. Slashes refer to alternatives within a pattern, while carets are used to denote a group within a pattern.).
Concepts Missing in SNOMED CT Some concepts were missing in SNOMED CT. Among Adverse Events, errors in prescription or administration of a drug are under-represented in SNOMED CT, and concepts such as therapy cessation, device leaks/breakage, off-label use, product contamination, tampering, counterfeiting and quality issues may be expected to be missing.
Omissions of clinical coverage include multiple drug resistance (to antibiotics), propofol infusion syndrome, compulsive shopping behavior, and intrauterine device migration, paternal drugs affecting fetus. Among Indications, concepts not expected to be in SNOMED CT are 'Drug use for unknown indications' (the highest-frequency indication); 'evidence-based treatment' and 'unevaluable event'. Clinical coverage omissions are breakthrough pain (seen in patients receiving narcotics for terminal illness) and 'bone marrow conditioning regimen'. Some of the indications terms are also Adverse-Event Terms (paternal drugs affecting fetus, off-label use). The common concept of post-procedural complications is not represented in SNOMED CT and needs to be composed. A family of MedDRA Preferred Terms that required three SNOMED CT concepts to map was the qualitative results of therapeutic drug monitoring. These had to be expressed using SNOMED CT concept 365750008 ('Finding of therapeutic drug level'), the drug family (e.g., anticonvulsant), and the qualitative result.
Unmapped MedDRA concepts matching single SNOMED CT concepts What was surprising was that about 30% of the 'unmapped' Preferred Terms for both indications and Adverse Events were found to map to single SNOMED CT concepts, indicating insufficient checking of these Preferred Terms during the MedDRA-UMLS curation process prior to characterizing them to distinct concepts in UMLS. This missed synonymy results in redundancy in UMLS content. Many of these were synonyms (e.g., dysphemia C1096340 = stuttering C0038506); word variants (feeling guilty C0877289 = feeling guilt (finding) C0018379); abbreviations (hip dysplasia C1328407 = congenital acetabular dysplasia (disorder) C0431952 - hip dysplasia, by definition, is never 'acquired').
The problem of missed synonymy in the UMLS was identified by Hole and Srinvasan in a 2000 paper and is admittedly a difficult one to solve. As we emphasize shortly, the concept redundancy problem is much more prominent for MedDRA's lower-level terms, many of which are synonyms for existing concepts rather than concepts in their own right. Issues with the MedDRA content in UMLS The process of integrating a source vocabulary into UMLS involves identifying the source-vocabulary concepts that correspond to existing UMLS concepts. Concepts where such correspondences are not found are designated as new concepts that will be assigned UMLS Concept IDs. However, the NLM performs limited curation, relying partly on automated methods, and to some extent on the diligence and knowledge of source-vocabulary curators of the individual source vocabularies for this process. In any case, errors in the original MedDRA content can propagate to UMLS.
Several types of errors can be detected in the source-vocabulary-to-UMLS mapping process, but their detection typically requires content expertise and manual inspection; some of these, indicated with a double asterisk, are due to undetected problems in the original MedDRA content. Missed Synonymy: Many concepts in MedDRA become new, duplicated concepts in UMLS: We have provided some examples earlier. Additional causes of missed synonymy include British vs. American spellings: For example, both 'Aluminium' (IUPAC/British) and 'Aluminum' (US) occur in phrases involving the metal. For example, we have the MedDRA derived 'Blood aluminium (& level (& serum))' C1578975' and SNOMED CT derived 'Serum aluminum level' C1318288. Improper Designation of Synonymy: Many pairs of distinct concepts are treated incorrectly as though they were synonyms. ○.
In the case of qualitative laboratory results, MedDRA does not appear to distinguish 'increased' from 'high', or 'decreased' from 'low': it treats these pairs (loosely) as interchangeable synonyms. Thus, there are the concepts 'Digoxin level high' C0581164, and 'Digoxin level decreased' C0920128), but there is no concept 'Digoxin level increased'. Strictly speaking, 'increased' and 'decreased' imply comparison to a previous value, which has relevance to the therapeutic drug monitoring that is employed for Digoxin, while 'high' and 'low' refer to values above or below normal/therapeutic ranges. SNOMED CT differentiates between 'high' (synonym 'elevated') and 'increased' by placing them in different sub-hierarchies. ○. MedDRA tends to use 'carcinoma' as a synonym for malignancy/cancer, whereas the term strictly refers to a malignancy of ectodermal or endodermal origin, as opposed to a 'sarcoma' that derives from mesoderm. Thus, MedDRA has the concept of 'gastrointestinal carcinoma', but does not record the (admittedly rarer) concept of gastrointestinal sarcomas, or the general concept 'gastrointestinal cancer' as a distinct concept.
Certain medical phrases that commonly occur in concepts are used loosely, so that they become new concepts in UMLS that, on closer inspection by someone with a background in laboratory medicine, would turn out to be invalid. For example, MedDRA's use of 'Blood' encompasses serum, plasma and blood as the sample source, while SNOMED CT's use is precise. So the MedDRA-derived 'blood prolactin' C0853129 does not exist as a SNOMED CT concept (whole blood is not used for prolactin assays, so that the concept of a 'blood prolactin assay' is invalid), though 'plasma prolactin' C0857712 does. The unclear relationship between MedDRA preferred terms and lower-level terms results in spurious concepts in UMLS and inaccurate relationships.
For example, In the UMLS-MedDRA content, 'antimony normal' C0861045 is treated as a distinct concept from 'blood antimony normal' C0855863. Interpreted in isolation in UMLS, the former concept is inherently ambiguous (it does not specify the tissue that was sampled).
Inspection of the details of the two concepts, however, reveals that in MedDRA, 'antimony normal' is a lower-level term corresponding to the preferred term 'blood antimony normal'. This should indicate that it is a synonym: it cannot be a more specific type of antimony measurement, since 'any' tissue is more general than 'blood'. Note that, this concept is also meaningless clinically: organic antimonials are used only in the treatment of schistosomiasis and leishmaniasis, and the 'normal' level is zero. Sometimes, MedDRA concepts are matched to the wrong UMLS concept. An example is 'Chemistry', which is matched to C0007996, which refers to the science (like physics and biology). The term 'chemistry', however, is known to be a homonym (a word with multiple, separate meanings) in English, and an inspection of the MedDRA-derived relationships of this concept in UMLS reveals that it is an Lower-level term corresponding to the Preferred Term 'Laboratory Procedure', indicating that it is really a synonym (a non-preferred, abbreviated form) for 'Serum Chemistry Test'. Many scientific phrases are semantically ambiguous in isolation, and the accepted way to address these is by the use of descriptive concept definitions (a mammoth curatorial task where all existing terminologies fall short) and/or the labeling of certain terms as ambiguous (a process followed by SNOMED CT and UMLS).
MedDRA, however, lacks concept definitions entirely, and there is no recognition or labeling of term ambiguity within its content: the meaning of a term must often be inferred from its position in a hierarchy. Consequently, errors of this kind are less likely to be detected. As a consequence of the above issues, the existing mapping in UMLS between SNOMED CT and MedDRA is problematic and needs to be carefully checked. In particular, the excessive incorporation of synonymous MedDRA Lower-level terms as new concepts in UMLS vitiates UMLS's intended role as a 'Rosetta stone'. Dealing with MedDRA Concepts based on Laboratory Parameters As discussed previously, to map a large number of MedDRA concepts based on laboratory parameters to SNOMED CT equivalents, one needs to combine the concept of the laboratory test measurement with a 'qualifier' concept describing the qualitative result of the result, e.g., normal, high or low.
This approach may satisfy the objective of mapping, but it does not address the problem of analyzability of the resulting SNOMED CT-encoded data. In the EMR, laboratory data is typically recorded in structured form rather than reproduced in the unstructured clinical narrative. The EMR's laboratory-data subsystem has standard methods of determining whether a given result is in the normal range, based on reference/laboratory standards and the patient's age and sex: the clinician can additionally bring information on other physiological states such as pregnancy to bear on the result. The task of generating appropriate MedDRA codes from structured laboratory data is algorithmically far simpler than trying to do the same with narrative text: such text may contain only the numerical values of the lab parameters, whose names are often reported in abbreviated form without mention of reference range or even units.
Laboratory measurements are currently not modeled in detail in SNOMED CT: they are mostly 'primitive' concepts rather than fully defined. This makes such mappings less useful than mappings to, say, clinical diagnoses. It is well known that 'Qualifier' concepts, such as used to describe qualitative results, are currently one of the least developed aspects of SNOMED CT: Rector and Brandt show that for many circumstances where they are used, more formal approaches would be preferable. They do not allow even limited electronic reasoning of the kind that is useful for Adverse Events - for example, that for certain tests, 'abnormal' and 'high' are synonymous, while for others (such as serum electrolytes and hormone levels), both 'high' and 'low' are abnormal results. This is partly because of the lack of any detailed computable semantics associated with individual qualifiers, which makes it easy to misuse 'elevated' when 'high' is intended, for example.
The use of ordinal domains -sets of permissible values for a laboratory-result concept that can describe a result qualitatively, based on a quantitative definition of normal - allows straightforward electronic reasoning. Such reasoning is implemented routinely by laboratory reporting systems that place an 'H(igh)' or 'L(ow)' against a numeric value, and would be extremely difficult if a purely qualifier-based approach to reasoning were adopted. The lack of ordinal-value support is a common problem in ontologies that is not limited to SNOMED CT. There is no intrinsic reason, however, why such support - a standard aspect of database/analytics knowledge representation for over three decades - cannot be systematically integrated with ontologies in knowledge domains where such support is called for. The latest incarnation of the Web Ontology Language, OWL 2, seems to be moving in this direction, with improved support for mathematical operations as well as more expressive constraints. The SNOMED CT concept model for observables is under active revision, but its current draft version (0.03) does not provide support for ordinal-value representation.
Toward a Comprehensive Ontology of Adverse Events In this section, we discuss the implications of the work described. Even if NLP techniques are able to match concepts in clinical text to Adverse Events with high accuracy, they do not address the problem of eventually aggregating the results in meaningful ways for analysis. In clinical narrative, certain concepts may be specified explicitly by the caregiver, while at other times they may be unstated, and their presence must be inferred from their known relationship to other concepts that occur in the narrative. For example, in the paper of Wang et al (the Columbia group) , phrases encountered in various patients undergoing treatment with bupropion (used as an anti-depressant as well as for smoking cessation) included 'extrapyramidal sign', 'stiffness', and 'motor retardation'. The authors do not recognize that the latter two symptoms are part of the extrapyramidal syndrome when occurring together (though each in isolation can have other causes), and an analysis that treated these terms as isolated entities would under-count the extrapyramidal findings. (MedDRA contains information about sets of individual findings that, when co-occurring, suggest specific syndromes. This information, the Standardized MedDRA Queries (SMQs), was created to facilitate data mining, and there is already an SMQ for Extrapyramidal Syndrome.
The authors did not use SMQ data, which is available in the UMLS Rich-Release format, to attempt to improve the accuracy of their results.) The availability of high-quality adverse events information content, which reliably records relationships between Adverse-Event concepts more comprehensively than MedDRA does currently, can improve the quality and productivity of Adverse-Event data analysis and data-mining, by minimizing the effort involved in ad-hoc creation of aggregate groupings that need to be replicated by every research group working with such data. The availability of Gene Ontology has had such benefits in the gene-expression microarray field, by facilitating the summarization of signals from thousands of genes into fewer, more readily interpretable categories using gene-family and pathway labels. An Adverse-Events ontology does not currently exist. The work reported in has, however, explored the manual construction of such an ontology for the limited domain of hepatitis. MedDRA's design is not sufficiently robust to serve as the foundations of such an ontology, though its Preferred Terms may serve as the nodes of interest, and the SMQ content is also essential.
The subset of SNOMED CT that maps to MedDRA (along with intermediate SNOMED CT concepts in the network that are discovered in the cross-mapping process) is more suitable for the ontology scaffolding. The work described in , has explored and confirmed this possibility for limited sub-domains such as 'hemorrhage': this work has identified the need for new inter-concept relationship types (attributes) that are specific to the adverse-event domain. The work of Bodenreider has also explored such issues, employing cross-mapping from MedDRA to SNOMED by automated approaches to actually quantify the intermediate-level SNOMED CT concepts. The major use-case for a standardized, validated and freely available adverse-event ontology is to serve as the basis for eventually encoding existing knowledge about drug or device-related adverse events. Currently, most commercially distributed drug databases record adverse effects as narrative text reproduced from the FDA package insert: where information is encoded, International Classification of Diseases (ICD) diagnosis codes are used, so that the numerous (non-billable) subjective or objective findings that are not full-fledged diagnoses are not represented. The variability of narrative text makes it difficult to answer the question: given the presence of a particular clinical finding, which of the medications that the patient is taking could be responsible, and what is the likelihood (expressed on an ordinal scale) of individual medications contributing? It is clear that many of the issues involved in knowledge representation (including representation of SMQs) go beyond the strictly 'ontological' - indeed, existing ontology-modeling tools and paradigms may prove a poor match for several aspects of the modeling of the adverse-event component alone.
The effort required will be vast, requiring the resources of national/international organizations, but we hope that the initial exploration described here will provide signposts to potential minefields. Limitations of the present work The limitations of this work include the following:. The mappings that we have performed may contain errors, or be disputed by others.
This paper is concerned primarily with the discovery of composition patterns as well as the MedDRA quality issues that were discovered during the attempted mapping. We have, however, provided a downloadable online appendix containing the mappings (as an Excel spreadsheet) as a companion to this paper. The numerous existing mappings of MedDRA to SNOMED CT in UMLS were not checked exhaustively: it is likely that there may be errors in addition to the ones that were caught in our exploration. Mappings between any two vocabularies with different underlying designs and incomplete overlap are necessarily directional. Our work only considers mapping from the non-compositional, smaller, MedDRA to the compositional, larger SNOMED CT. The reverse scenario - mapping SNOMED CT-encoded content from the clinical narrative to MedDRA concepts - has not been addressed. This can be challenging in cases where SNOMED CT concepts are recognized in clinical text by automated methods: such methods by their nature tend to discover simple, 'primitive' concepts rather than highly composite ones (especially those that involve negation).
Also, certain MedDRA concepts such as 'wrong technique in drug usage process' must be inferred from the narrative, because they are rarely if ever explicitly stated as such. Conclusions The design of MedDRA, in particular the failure to distinguish between lower-level terms that are synonyms of preferred terms as opposed to those that are distinct but finer-grained concepts, poses problems for the MedDRA content in UMLS. In addition, the existing integration approach has resulted in a significant proportion of duplicate concepts being added to UMLS. This content needs a detailed audit, because most researchers use UMLS as the source of MedDRA content rather than paying a significant subscription fee to the MedDRA Maintenance and Support Organization.