| Oracle® Thesaurus Management System User's Guide Release 4.6.2 Part Number E18827-01 |
|
|
View PDF |
| Oracle® Thesaurus Management System User's Guide Release 4.6.2 Part Number E18827-01 |
|
|
View PDF |
This section describes the following administrative tasks in Oracle Thesaurus Management System (TMS):
TMS enables data access to be controlled in multiple dimensions. First, database roles control what kind of activity each user is allowed to complete, such as classification, item definitions, item approval. Then, after a user has role assignments, your organization can choose to further specify the domains and/or dictionaries in which this user can perform these activities by assigning certain predefined Data Access Groups (DAGs) to that user. Database roles are created during installation; DAGs are defined in the UI.
This section includes the following topics:
This section illustrates the predefined roles, with the functions permitted and the menu option associated with each:
A description of each predefined role is included below.
In addition, you can see the grants that are predefined for each of these roles by logging into SQL*Plus as SYSTEM and entering the following:
select *from dba_tab_privs where grantee='TMS_ROLE';
This role grants access to the Security menu, which contains Define Users, Define Security Columns, and Maintain DAGS windows, as well as the DAG and Setting Inconsistencies report and the Create/Drop EXT_Value Indexes job. The three windows allow you to create new users, define their privileges, and migrate user information from an Oracle Clinical database. The DAG and Setting Inconsistencies report displays inconsistencies between users' data access via DAG and their profile settings. The Create/Drop EXT_Value Indexes job creates or drops indexes on external value columns for performance.
All users are granted this role by default, which gives them access to items under the Repository menu. Thus, all users can browse repository data, VT classification data, and Informative Note data; and all users can run the Date Comparison Report, Dictionary Comparison Report, Dictionary Export Report, and view the HTML Browser.
All users are granted this role automatically. This role enables you to view the TMS menu and the Favorites menu.
This role gives users access to the windows under the Task Allocation menu. In these windows, users can set up task allocation and allocate tasks—approving VTAs, approving Action assignments, and classifying omissions—to other users.
Note:
Users with this privilege can allocate/reallocate/deallocate any task in any domain/dictionary, regardless of their own DAG assignments. However, they can only allocate tasks to users whose DAG assignments and database roles give them access to the data required to perform the task.Note:
Users with TMS_CLASSIFY_PRIV and TMS_APPROVE_PRIV have access to the Task Allocation by Term window, where they can deallocate terms assigned to themselves, and, depending on the value of the reference codelist setting DEALLOCONLY, reallocate those tasks to other users.This role gives users access to the Approve VTAs and Approve Action Assignments window under Omission Management. In this window, users can approve and unapprove VTAs, and create workflow Informative Notes for the VTA approval process.
This role gives users access to all the items under Omission Management and also the Task Allocation By Term window under Task Allocation. However, users who do not also have tms_approve_priv cannot approve VTAs or Action assignments. Users with tms_classify_priv can classify verbatim terms, apply actions to omissions, and run the VTA Creation Report and VT Domain Differences Report.
This role give users access to all items under Definition and to the Reports tab in the HTML Browser. Users with tms_define_priv can define dictionaries, domains, external systems, Global Actions, search objects, TMS settings, named relations, and Informative Note Attributes. Users can also run Synchronization, refresh the context server index, analyze tables, and purge classified omissions.
This role gives users access to every item under Dictionary Upgrade where you can view and manipulate verbatim terms and their relations in the predictionary tables before Activation.
This role gives users access to every item under Document Management except the Maintain Documents window (which requires tms_doc_maintain). Users with tms_doc_config can maintain Document Servers, define proxy servers and define refresh rules for them, maintain Document Index error logs, create and refresh the Document Index, refresh Document Servers, force a Document Server refresh, and optimize the Document Index.
This role gives users access to the Maintain Documents window under Document Management. This window enables users to edit information in the Document Repository, which powers document searches in the HTML Browser.
This role gives users access to the menu item DSI Maintenance including the Maintain DSI Files window and several jobs related to data exchange between TMS and disconnected systems.
This role gives users access to special integration features in the API, but does not unlock any menus or windows in the application.
This role gives users access to all items under the Repository Maintenance and Translation Reports menus. Repository Maintenance tasks include: creating and maintaining and deleting terms, relations, and Informative Notes; maintaining dictionary loading error logs; running the Preliminary Repository Report, and running Activation.There are three reports under the Translation Reports menu: Inconsistent Dictionary Codes, Duplicate Dictionary Codes, and Inconsistent Dictionary Relations.
This role give users access to all items under VTA Maintenance. Users with this role can promote or demote VTAs, maintain actions, reclassify and declassify verbatim terms, perform high-level reclassification, copy domains, maintain domain copying error logs, and run the Nonapproved VTs Report, Classification to a New Domain Report, and the VT Modifications Report.
This role enables Oracle Clinical and Oracle AERS users that do not have any other TMS privileges to use the HTML Browser for drilling down to external system data. You may want to grant this role to external system users who require access to source data searches in the HTML Browser, but do not need access to any TMS windows.
In a new installation, you must use a script to create one user with the OPA_ADMIN role. That administrator can then use the Define Users window to create user accounts for all the other users in this database; see "Defining Users" for instructions.
Note:
If you are upgrading to TMS Release 4.6.2 from Release 4.5.2 you may need to use this script as well.To create a new account for a TMS administrator:
Connect to SQL*Plus as SYSTEM and run the following script:
opa_home\tms\install\tmsadduser.sql
Enter the user's first name.
Enter the user's last name.
Enter a password for this user. Your input is hidden.
The script creates a user account for the user you specified and gives the user the OPA_ADMIN database role.
Note:
You cannot use this script to create a nonadministrator user.Functions permitted at local (non-master) instances are limited to the following main menu and submenu options.
Local Reference Codelists and Maintain Settings windows; and all Jobs: Synchronize Dictionary Data, Refresh Context Server Index, Analyze Tables, Purge Classified Omissions, Create Source Terms Views, Refresh Source Term Mat. Views. Initialize Disconnected System Integrations.
Define Users, Define Security Columns, and Maintain DAGs windows; DAG and Setting Inconsistencies report, Create/Drop EXT_VALUE indexes job.
High-Level Reclassification window; Classification to a New Domain, VT Modifications, and X Areas with Outstanding Changes reports.
Classify VT Omissions and VT History windows; VTA Creation Report, Classification Statistics Report,and VT Domain Differences.
Browse Repository Data, Browse VT Classification Data, Browse VT History windows; Date Comparison, Dictionary Comparison , Dictionary Export reports.
Inconsistent Dictionary Codes, Duplicate Dictionary Codes, and Inconsistent Dictionary Relations reports.
All document management options are available at all instances. These include these windows: Maintain Documents, Maintain Document Servers, Define Document Server Refresh Rules, Define Proxy Server, and Maintain Document Index Error Logs. Jobs include: Create Document Index, Refresh Document Index, Refresh Document Servers, Force Document Server Refresh, and Optimize Document Index.
This section contains the following topics:
The OPA_ADMIN database role is required to access the Define Users window. See "Enrolling an Administrator" for information on creating a user account with the OPA_ADMIN database role.
When you create a new user in the database, you define the user's first and last name, user name in the database, and set a password. Additionally, you can add an email address and set superuser status.
To define a new user, from the Define Users window under the Security menu:
Define the Account Name, which is the user name a user specifies upon login to the application. The account name is often prefixed with OPS$ but this prefix is not required.
Enter the user's First Name and Last Name. The first name and last name appear in the menu bar when this user is connected to TMS.
Set the Super User? field to either Yes or No. If this person is a superuser then no Data Access Group information is stored (see "Assigning Data Access Groups to a User"). Superusers have access to all data. Only superusers can run the following jobs and reports:
all Disconnected System Integration (DSI) jobs, including importing and exporting data
Autoprocess VTAs
Predict VTA Report
Site Impacts Report
Omission Impacts Report
Cross Dictionary Impacts
X Areas with Outstanding Changes
Classification Statistics Report
Date Comparison
Dictionary Comparison
Dictionary Export
Set the Load User? field to either Yes or No. If set to Yes, this person can load dictionaries into the predictionary tables. Most TMS users do not need this ability.
(Optional) Enter a Comment about this user. Comment information can help administrators identify users, and thus maintain each user's privileges more effectively.
(Optional) Enter an Email Address for the user. This field is added to support future functionality.
Click Create Schema. The "Password to be Assigned to User Account Name" window opens.
Enter and confirm the password for this user, and click OK.
If the password entries match, TMS adds this user to the OPA_ACCOUNTS table and TMS_ACCOUNTS table, and grants the TMS_ACCESS role to the account. Proceed to "Assigning and Revoking Roles" to assign additional roles for this user.
Note:
Users who work on replicated studies and who need to see source term-related values using external value filters must have an account on both the master and local databases. For example, if a user filters by an external value such as Study when querying for omissions, and the requested study has source terms entered on a database on which the user does not have an account, an invalid username/password error is displayed.TMS uses menu-based security, so roles give a user access to particular TMS menus or windows. The TMS role TMS_MAINTAIN_PRIV, for example, allows a TMS user to use all of the windows and batch jobs under the Repository Maintenance menu.
This section describes how to assign roles to, and revoke roles from, a TMS user.
To assign roles to an account:
Select the user in the Define Users window, then click Assign Roles.
The "Roles to be Assigned to User Account Name" window opens, displaying the TMS roles that this account does not currently have.
Highlight the roles you want to grant to this account. You can Shift-click to select multiple consecutive rows, or Ctrl-click to select multiple non-consecutive rows.
Click OK. TMS grants the role or roles you selected to this account.
To revoke roles for an account:
Select the user in the Define Users window, then click Revoke Roles.
The "Roles to be Revoked from User Account Name" window opens, displaying the roles currently granted to this account.
Highlight the roles you want to revoke from this account. You can Shift-click to select multiple consecutive rows, or Ctrl-click to select multiple non-consecutive rows.
Click OK. TMS revokes the role or roles you selected to this account.
You can change any user's password in a database where you have administrator privileges.
To change a user's password:
Start a SQL*Plus session as SYSTEM.
Issue the following alter user command:
alter user usernameidentified by new_password
Data Access Groups (DAGs) work in conjunction with roles to control a user's access to TMS data. You can use them to fine tune the data that a particular user or class of users can operate on. For example, the user with TMS_MAINTAIN_PRIV would still be able to access all of the windows and batch jobs under the Repository Maintenance menu, but if you also assign a DAG that only allows access to MedDRA, then he would see only items relevant to MedDRA.
If a person is designated as a superuser in the Define Users window, he or she belongs to all DAGs and has access to all data.
To assign a DAG:
Select the user in the Define Users window, then click Assign DAGs.
The "Assign DAGs to user Account Name" window opens. If the user has been assigned any DAGs, they are listed.
Place the cursor in an empty field under Dag Name. From the LOV, select the DAG to assign.
Click OK. TMS assigns the DAG or DAGs you selected to this account.
This section applies only to TMS installations that are integrated with Oracle Clinical.
TMS stores general user account information in the OPA_ACCOUNTS table and TMS-specific user account information in the TMS_ACCOUNTS tables. See the Oracle Thesaurus Management System Technical Reference Manual for details.
If you have already set up user accounts in Oracle Clinical, you can migrate all account information from ORACLE_ACCOUNTS to OPA_ACCOUNTS, as follows:
In TMS, go to Security, then select Define Users.
Click Get O*Clinical Account Data.
The system inserts all records from the ORACLE_ACCOUNTS table into the OPA_ACCOUNTS table. The default comment text for each record is "Maintained in Oracle Clinical."
You must continue to maintain these accounts in Oracle Clinical.
This section includes the following topics:
In TMS, database roles dictate which windows in the user interface a user can access. For users assigned to one or more Data Access Groups, their DAG assignments dictate the data they see in TMS windows and in the HTML Browser, and whether or not they can operate on TMS data in specific dictionaries and/or domains.
When you define a DAG:
You can specify whether users in the group can make changes or only read data.
You can specify whether users in the group can see data that originated in one or more specific external systems, and from a particular project or study, for example.
You can specify whether users in the group can see data that originated in one or more specific databases.
You can specify whether a user can see only his or her own task assignments and/or those of which specific other users.
You define DAGs in the Maintain DAGs window and then assign users to the group either there or as you create user accounts. A single user can be assigned to multiple DAGs. The user then has access to the sum of data allowed by all his or her DAG assignments. Alternatively, a user can be designated as a Superuser. Superusers can see all data and cannot be assigned to any DAGs.
The OPA_ADMIN database role is required to access the Maintain DAGs window.
Before you define any DAGs, you must specify which TMS table columns—each of which stores a particular type of data—are available to include in DAGS; if a column is available to DAGs, a particular DAG can limit the data its users can see to one or more values stored in that column in TMS. If the column is not available to DAGs, data for all its values is always viewable to users with normal security access.
The columns available for use in DAG security are:
DEF_ DICTIONARY_ID. This column contains the IDs of dictionaries defined in TMS. If you make this column available for use in DAGs, you can allow users assigned to DAGs to see data associated with only one or a few dictionaries.
DEF_DOMAIN_ID. This column contains the IDs of domains defined in TMS. If you make this column available for use in DAGs, you can allow users assigned to DAGs to see data associated with only one or a few domains.
DEF_INSTANCE_ID. This column contains the IDs of your TMS databases. If you make this column available for use in DAGs, you can allow users assigned to DAGs to see data collected on only one or a few databases.
DEF_INTEGRATION_KEY. If you have integrated one or more external source data systems with TMS, this column holds the name of the system(s). If you make this column available for use in DAGs, you can allow users assigned to DAGs to see data associated with only one or a few external systems.
EXT_VALUE_1. This column holds external system data associated with a term and stored in the EXT_VALUE_1 column in the tables TMS_SOURCE_TERMS and TMS_VT_OMISSIONS. For external systems other than Oracle Clinical, you specify the data stored in this column; see "Setting Up External System Columns and Details". For Oracle Clinical, this column stores the name of the Project associated with a source term. If you make this column available for use in DAGs, you can allow users assigned to DAGs to see data associated with only one or a few Oracle Clinical projects, for example.
EXT_VALUE_2. This column holds external system data associated with a term and stored in the EXT_VALUE_2 column in the tables TMS_SOURCE_TERMS and TMS_VT_OMISSIONS. For external systems other than Oracle Clinical, you specify the data stored in this column; see "Setting Up External System Columns and Details". For Oracle Clinical, this column stores the name of the Project associated with a source term. If you make this column available for use in DAGs, you can allow users assigned to DAGs to see data associated with only one or a few Oracle Clinical projects, for example.
ASSIGNED. This column holds the user name of the person to whom a term is assigned as a task allocation because the term requires work: approving a VTA, approving an Action assignment, or classifying an omission. If you make this column available for use in DAGs, you can allow users assigned to DAGs to see terms assigned only to themselves (LOGIN_USER) or to specific other users.
To make columns available for use in DAGs, do the following:
In the Security menu, select Define Security Columns. The Define Security Columns window opens, displaying each column in a different row.
For each column, select a value for the following fields:
Used?. If set to Yes, you can define DAGs to control whether users can see the corresponding field in TMS windows. If set to No, DAGs cannot control whether users see the field. The field is visible or enterable to anyone with access to the window.
Note:
You can change the Used? setting from No to Yes at any time. After a column is included in a DAG definition you can no longer change the setting from Yes to No.Create Index?. You can set this flag to Yes only for the EXT_VALUE columns. If set to Yes, when you run the Create/Drop EXT_VALUE Indexes job (under the Security menu) TMS creates an index on the values in this column to speed performance when these values are used in the context of security. If set to No, TMS drops the index when you run the same job.
Save. TMS enters values in the Creation Time and Created By fields. If you modify the settings for any column, TMS enters values in the Modification Time and Modified By columns.
The process of defining a Data Access Group includes three parts: creating the DAG, specifying the DAG rules, and assigning users to the DAG. There are three tabs in the Maintain DAGs window, one for each task.
To create a DAG:
In the Security menu, select Maintain DAGs. The DAGs tab is displayed.
On the DAGs tab, enter a Name and a Short Name for the DAG.
Select an option for the Modify Flag? option. If you want users assigned to this DAG to be able to modify data in the windows to which they have DAG access, select Yes. If not, select No.
Enter a Status of Provisional. You can set it to Active any time after the definition is completed, including defining the DAG rules. You can add users to a DAG whose status is either Provisional or Active. Only active DAGs are used to enforce data security.
Save. Click the DAG Rules tab and select settings as described below.
This section includes the following topics:
In the DAG Rules tab you specify the data that users assigned to the DAG can view. For one or more of the columns you selected in the Define Security Columns window, you can specify values to determine which data users in this group can see. For example, you can specify a particular dictionary or set of dictionaries. Users assigned to the DAG can then see data related to only those dictionaries (or other dictionaries to which they have access through another DAG).
You can also specify the type of operations that a user can perform in a dictionary or domain by requiring a DAG role for a particular dictionary or domain, and then specifying the role assigned to users in the DAG; see Example 3-1, "DAG Example 1".
DAG Roles You can use DAG roles for the dictionary and domain columns to determine which operations users with normal security access to various TMS windows can perform there on which dictionary and/or domain data. The DAG roles are:
TMS_CLASSIFY allows users assigned to the DAG to perform classification operations in the Classify VT Omissions window in a particular dictionary and/or domain, if they also have the database role TMS_CLASSIFY_PRIV.
TMS_APPROVE allows users assigned to the DAG to perform approval operations in the Approve VTAs window in a particular dictionary and/or domain, if they also have the database role TMS_APPROVE_PRIV.
TMS_MAINTAIN allows users to perform all operations in all windows in the Repository Maintenance and Translation Reports menus in a particular dictionary and/or domain, if they also have the database role TMS_MAINTAIN_PRIV.
TMS_DUPG allows users to perform all operations in all windows in the Dictionary Upgrade menu in a particular dictionary and/or domain, if they also have the database role TMS_DICTUPG_PRIV.
TMS_RECLASSIFY allows users assigned to the DAG to perform reclassification operations in the Reclassify Verbatim Terms window and in the High-Level Reclassifications window in a particular dictionary and/or domain, if they also have the database role TMS_RECLASSIFY_PRIV.
Data Access Group 12345 has the following DAG rule defined for the dictionary column (DEF_DICTIONARY_ID), for which a DAG Role is required:
For the value MedDRA, the DAG roles specified are TMS_CLASSIFY and TMS_APPROVE.
For the value WHO-Drug, only the DAG role TMS_CLASSIFY is specified.
If you assign a user who has all TMS database roles assigned to this DAG, the user can perform Classify and Approve activities on MedDRA. However, on WHO-Drug, the user can only perform Classify activities, and not, for example, Approve activities.
User A belongs to only one DAG, and that DAG specifies MedDRA as the only dictionary he can access. Therefore, in any windows he can open, he can view only MedDRA data. User A has two database roles: TMS_CLASSIFY_PRIV and TMS_APPROVE.
User A can do the following:
Open Classify VT Omissions window (because he has the database role TMS_CLASSIFY_PRIV) and open the Approve VTAs window (because he has the database role TMS_APPROVE_PRIV).
See data from MedDRA in both windows (because MedDRA is specified as a value for the DEF_DICTIONARY_ID column in his DAG).
Classify verbatim terms to MedDRA terms ((because his DAG has Roles Required for the column DEF_DICITONARY_ID, MedDRA defined as a value for that column, and the DAG role TMS_CLASSIFY is specified for that value).
However, he cannot approve VTAs in the Approve VTAs window because his DAG has Roles Required for DEF_DICTIONARY_ID, MedDRA defined as a value for that column, and TMS_APPROVE is not specified as a DAG role for MedDRA.
After you have created a DAG, define rules for it:
In the Maintain DAGs window, DAGs tab, select the DAG for which you want to define rules.
Click the DAG Rules tab. TMS displays the DAG Rules tab with the DAG name and short name displayed at the top of the tab.
Click in the first empty row in the Columns section, Name field.
Click the ellipsis (…) to invoke the list of values. TMS displays a list of the columns you defined as available to DAGs; see "Defining Security Columns".
For each column you select, specify the following:
Role Req'd?. TMS allows setting this flag to Yes only for the DEF_DICTIONARY_ID (dictionary) and DEF_DOMAIN_ID (domain) columns.
If set to No, users assigned to this DAG can perform any transactions on the data they can see in the windows they can open.
If set to Yes, users assigned to this DAG can perform only certain transactions (specified in the Roles section for each column value) on the data they can see (specified in the Values section) in the windows that they can open.
Values. In the Values section, specify every value that applies for the currently selected column in the Columns section. For most columns, no value appears in the External System field. Click in the Column Value field and select a value from the list of values. If you want to specify more than one value, select one in the next row.
The list of values for the Assigned column includes the predefined value [LOGIN_USER]. If you select this predefined value, the user currently logged in to TMS can see the tasks assigned to himself or herself.
For information on the external system-related columns, see "Rules for External System Data".
Roles. If you set Role Req'd? to Yes, you must specify at least one role for each column value. For example, if you specified Role Required for the DEF_DICTIONARY_ID column, and specified MedDRA as one of the values for the column, the Roles you specify for MedDRA determine what operations users in this user group will be able to perform on MedDRA terms. If you specify TMS_CLASSIFY, users with access to the Classify VT Omissions window will be able to classify verbatim terms to MedDRA terms. If you do not specify TMS_CLASSIFY, users with access to the window will be able to see MedDRA terms but will not be able to perform any classification operations on them.
Save. Repeat for each column you want to include in the DAG.
To limit users' access to data from a particular external system, select the DEF_INTEGRATION_KEY as a column, then select the particular external system to which you want to allow access in the Column Value field.
To allow access to a particular level of information within an external system, use the EXT_VALUE_1 and EXT_VALUE_2 columns.
For Oracle Clinical, the EXT_VALUE_1 is predefined to hold project names and the EXT_VALUE_2 column is predefined to hold study names. For other external systems you define what data to store in these columns; see "Setting Up External System Columns and Details".
For example, if you specify Oracle Clinical as an external system value and then specify Project A as the only EXT_VALUE_1 value and Study A as the only EXT_VALUE_2 value, users assigned to this DAG can only view source terms that originated in Oracle Clinical Project A, Study A. They cannot view source terms from Project A, Study B, or source terms that originated in another external source data system.
To specify external system data to be accessible to users in this DAG, do the following:
In the Columns section, Name field, select EXT_VALUE_1 or EXT_VALUE_2 from the list of values.
With EXT_VALUE column selected in the Columns section, click the External System field in the Values section.
From the list of values, select the external system whose data you want users to be able to see.
Click the Column Value field and invoke the list of values. TMS displays the values stored in the EXT_VALUE_1 (or EXT_VALUE_2) column for the external system you selected. For example, if you selected Oracle Clinical as the external system, TMS displays Oracle Clinical project names.
From the list of values, select a column value.
Users in this DAG will be able to see data associated with the external systems and column values you specify, and they will not be able to see data associated with external systems and column values you did not specify. Repeat this procedure to allow access to additional values for the same external system, and to allow access to data from additional external systems.
Note:
If you use the EXT_VALUE_1 or _2 columns to specify access to data from a particular external system, you must also specify the external system itself as a value in the DEF_INTEGRATION_KEY column.Note:
For best performance, each time you add or delete a value from one of the EXT_VALUE columns, run the Create/Drop EXT_VALUE Indexes job.If your company is using the Task Allocation feature and you want to restrict users' ability to allocate tasks in certain dictionaries or domains, or restrict user's ability to see other users' assigned tasks, you can use DAGs to enforce those restrictions.
TMS allows users with task allocation privileges to allocate tasks to any user who is available for tasks associated with a particular dictionary. However, if the allocator is assigned to one or more DAGs, he or she can allocate tasks to other users only for the dictionaries he or she (the allocator) has access to through a DAG. The task-receiving user must have access to the same dictionary through a DAG as well (or as a superuser).
Example 3-3 DAG Definitions and Task Allocation
TMS user Ted has TMS_ALLOCATE_PRIV and is assigned to DAG 12345, which includes two dictionaries: MedDRA and WHO-Drug.
TMS user Alice is assigned to DAG 67890, which includes two dictionaries: MedDRA and CoStart.
Ted can assign Alice tasks related to MedDRA only; not WHO-Drug or CoStart.
Note:
The values of the Assigned column restrict the data that the user sees in Classify VT Omissions, Approve VTAs, Approve Action Assignments windows. They do not affect what the user sees in the Task Allocation windows. As long as the user has task allocation privilege, he can see all tasks (assigned to anyone) in the Task Allocation windows.You can assign users to a DAG either in the User Assignments tab of the Maintain DAGs window or in the Define Users window. In the Maintain DAGs window, you can add multiple users to a single DAG at the same time. In the Define Users window you can assign a single user to multiple DAGs at the same time. See "Defining Users" for further information.
To add users to a DAG in the Maintain DAGs window, do the following:
In the Security menu, select Maintain DAGs. The Maintain DAGs window opens.
Click the User Assignment tab. The User Assignment tab opens.
Click in the Account Name field in the first empty row. TMS displays … in the right corner of the field.
Click the … to retrieve the list of values including all user accounts available for assignment to a DAG (superusers are not included).
Select the user account you want to assign to the DAG. You can query in the Find field to narrow your search.
Repeat the procedure to add another user account in the next row as many times as necessary. If necessary, select Insert from the Record field to additional rows, one at a time.
Save. TMS assigns the users you specified to the DAG, which now controls their access to TMS data.
This section contains the following topics:
When you create a user account in TMS, you specify profile settings for the user. In addition, if the user is not a superuser you also assign the user to at least one Data Access Group (DAG).
DAGs determine which data the user can view, and profile settings determine which data a user views by default. TMS does not check or enforce that these settings match; therefore it is possible to set a user's profile to default settings for data the user cannot actually see. Use this report to determine if any users are currently in this situation.
It is also possible to create a user account and not assign the user to any DAGs. Users designated as superusers can see all data and cannot belong to a DAG. However, if you do not designate a user as a superuser and also do not assign him or her to a DAG, the user will not be able to do anything in TMS.
The DAG and Setting Inconsistencies Report shows the following:
A list of all non-superusers who are not associated with an active DAG.
A list of all non-superusers who do not have DAG access to the following default settings:
dictionary
domain
external system
external value(s)
To generate a DAG and Setting Inconsistencies Report, do the following:
From the Security menu, select the DAG and Setting Inconsistencies Report.
Enter a value for the General parameter Output. Select the format in which you wish to generate the report - HTML, PDF, RTF, XLS or XML. This is a mandatory field.
Enter a value for the Job Specific parameter Template. Select the template you want to use for this report. If your company has created a custom template, it appears in the list of values. The Oracle Template is the default template.
Submit the job. Select Job, then Submit, or click the Submit icon to generate the report in the selected output format.
A new browser window opens with the generated report.
Use this job to create or drop indexes on the column EXT_VALUE_1 and/or EXT_VALUE_2 in the TMS tables TMS_VT_OMISSIONS and TMS_SOURCE_TERMS. You specify which column or columns to create an index for in the Define Security Columns window (see "Defining Security Columns") but you must run this job to actually create the index.
For best performance, run this job whenever you add or remove values from the EXT_VALUE_1 or EXT_VALUE_2 columns in a DAG definition.
To run the job, do the following:
Under Job-Specific parameters, click in the Actions field and select a value from the drop-down list: Create Indexes or Drop Indexes.
Under Schedule, select a Report Server.
If you want to run the job at a later time, set the other scheduling parameters; see "Setting Up and Running Reports and Other Batch Jobs".
Submit the job.
TMS Settings are default values that populate many fields in TMS, such as Domain, Dictionary, and the fields that appear in the Filter window. You can establish settings that are company-wide, or specify profiles from which sets of TMS users will inherit settings values.
This section contains the following topics:
A profile is a catalog of TMS settings values. You can define profiles that specify one or more of the TMS settings, then assign any profiles to users to control their default behavior in TMS. For example, you can create a profile that defines default values for the Action Owner and External System. If you assign this profile to a user (see "User Profiles"), these settings could control that user's default settings for these two fields in TMS.
Two default profiles provide baseline settings for TMS. The Oracle profile includes a standard set of keys and settings that provide default settings throughout the system. The Company Settings profile establishes default values that are specific to your company. Company settings override Oracle settings, and provide a baseline set of values for all users in your company.
The additional, custom profiles you define enable you to set up more specific default values for groups of users. Custom profiles override both the Company Settings and Oracle profiles. You can set up as many custom profiles in TMS as you want, and assign multiple profiles to each user.
The user profile is the set of profiles that have been assigned to a user. For each profile that you assign to a user, you must define a Search Order Number. The Search Order Number shows TMS which profiles to consider first when a user profile contains multiple profile definitions.
TMS sets a user's default values by checking through each profile in the user profile:
TMS finds the first user profile (the user profile with the lowest Search Order Number) and sets the value of each TMS field that the setting specifies.
TMS then checks each subsequent user profile row in ascending order by Search Order Number. For each of these profiles, TMS sets defaults that have not been set by an earlier profile. If the first user profile created this user's default domain setting, the other profiles cannot override it.
The system then checks the Company Settings profile for other TMS settings that have not been specified for this user by any of the user's custom profiles.
Finally, TMS checks the Oracle profile for other unspecified TMS settings.
Each setting value controls the default behavior of one field in TMS. To determine your default domain, for example, TMS checks through your hierarchy of profiles for a value in the TMS_CURRENT_DOMAIN setting. The system then chooses that domain for you when you log in to TMS.
Many TMS settings control the default value for fields that also appear in the TMS filter windows. The following windows have filters: Approve VTAs, Reclassify Verbatim Terms, Classify VT Omissions, and Maintain DSI Files.
The Approve VTAs and Reclassify Verbatim Terms windows both use the Omissions Filter, with the same settings. The TMS_DSI settings control values in the Maintain DSI Files window. Enter values for TMS_DSI settings only if you are using the Disconnected System Integration feature, and only if you want a default value set in your filter for that window (see "Using TMS with Disconnected Systems").
For information on how to enter values for parent and child settings, see "Defining a Setting When No Parent-Child Setting Relationship Exists" and "Defining a Setting in Parent-Child Relationships".
Note:
You may need to log out and log in again for new settings to take effect.Settings are grouped according to the part of the application they control:
OPA settings control areas of the application that are common to all Oracle Health Sciences (formerly Oracle Pharmaceutical Applications) products.
OPA_JAVA_DATE_FORMAT: The default format for data values in Java activities in TMS. For example, dd-MMM-yyyy
OPA_JAVA_TIME_FORMAT: The default format for time values in Java activities in TMS. For example, kk:mm:ss
OPA_SQL_DATE_FORMAT: The default format for date values in SQL queries. For example, DD-MON-YYYY
OPA_SQL_TIME_FORMAT: The default format for time values in SQL queries. For example, HH24:MI:SS
OPA_UIX_MAX_ROWS: For UIX-based applications such as the HTML Browser, this setting determines the maximum number of records that queries will retrieve.
OPA_UI_COUNTRY: Two-letter short name of the default country. An LOV is available.
OPA_UI_LANG: Two-letter short name of the default language. An LOV is available.
TMS Forms settings control the default settings for the Oracle Forms-based TMS user interface.
The parent-level settings are:
TMS_CURRENT_ACTION_OWNER: This setting controls the default value for the Action Owner field.
TMS_CURRENT_ACTION_SYS: Controls the default value for the External System field.
TMS_CURRENT_ACTION_WKFLW: Controls the default value for the Action Workflow field.
TMS_CURRENT_ASSIGNED: Controls the default value for the Assigned field in the General tab of the Omission Filter.
TMS_CURRENT_DOMAIN: The domain that is selected for your profile by default. This setting is a parent key for TMS_CURRENT_DICTIONARY.
TMS_CURRENT_EXT_SYSTEM: The external system that is selected by default.
TMS_CURRENT_SYNC_INSTANCE: Controls the TMS DB field in the General tab of the Omission Filter and other Filter windows.
TMS_DSI_CURRENT_EXT_SYS…: From the list of values, select the name of the external source data system you most commonly use in Disconnected System Integration. This setting populates the External System field in the Maintain DSI Files Filter, and has a child and grandchild setting; see TMS_DSI_CURRENT_INSTANCE and TMS_DSI_CURRENT_X_AREA.
TMS_DSI_ERROR_PROCESS_STATUS: From the list of values, select N or Y (No or Yes). If N, the Error box for Process Status is deselected by default, and the system does not query for jobs that ended with a status of Error. If Y, the Error box for Process Status is selected by default, and the system queries for jobs that ended with a status of Error.
TMS_DSI_FATAL_PROCESS_STATUS: From the list of values, select N or Y (No or Yes). If N, the Fatal box for Process Status is deselected by default, and the system does not query for jobs that ended with a status of Fatal Error. If Y, the Fatal box for Process Status is selected by default, and the system queries for jobs that ended with a status of Fatal Error.
TMS_DSI_LAST_EXPORT_END_TS: If you will often search for files exported during a particular time period, enter the last day of that time period using the date format in your OPA_SQL_DATE_FORMAT setting. This setting populates the (Last Export Between…) And… field in the Maintain DSI Files Filter.
TMS_DSI_LAST_EXPORT_START_TS: If you will often search for files exported during a particular time period, enter the first day of that time period using the date format in your OPA_SQL_DATE_FORMAT setting. This setting populates the Last Export Between… field in the Maintain DSI Files Filter.
TMS_DSI_MANUAL_STATUS: From the list of values, select the import/export job manual status you most frequently want to query for, if any. The choices are: New, Pending, or Fixed. This setting populates the Manual Status field in the Maintain DSI Files Filter.
TMS_DSI_PROCESS_END_TS: If you will often search for files that ran during a particular time period, enter the last day of that time period using the date format in your OPA_SQL_DATE_FORMAT setting. This setting populates the (Process Between…) And… field in the Maintain DSI Files filter.
TMS_DSI_PROCESS_START_TS: If you will often search for files that ran during a particular time period, enter the first day of that time period using the date format in your OPA_SQL_DATE_FORMAT setting. This setting populates the Process Between… field in the Maintain DSI Files filter.
TMS_DSI_PROCESS_TYPE: From the list of values, select Export or Import. This setting populates the Process Type field in the Maintain DSI Files Filter.
TMS_DSI_SUCCESS_PROCESS_STATUS: From the list of values, select N or Y (No or Yes). If N, the Success box for Process Status is deselected by default, and the system does not query for jobs that ended with a status of Success. If Y, the Success box for Process Status is selected by default, and the system queries for jobs that ended with a status of Success.
TMS_DSI_WARNING_PROCESS_STATUS: From the list of values, select N or Y (No or Yes). If N, the Warning box for Process Status is deselected by default, and the system does not query for jobs that ended with a status of Warning. If Y, the Warning box for Process Status in selected by default, and the system queries for jobs that ended with a status of Warning.
TMS_DSI_X_AREA_STATUS: From the list of values, select Active, Complete, or Inactive. This setting populates the X Area Status field in the Maintain DSI Files Filter.
TMS_PROCESS_DICTIONARY If some dictionary/domain combinations require approval for VTAs or actions, you can use this profile setting allow one or more particular users to apply Answerable Actions directly in this dictionary (for any domain), with no approval or Internal Action required, and/or to create Approved VTAs directly, with no approval required. See TMS_ACTION_APPROVAL_REQUIRED and TMS_VTA_APPROVAL_REQUIRED.
Each of the following settings is dependent on one of the parent-level settings. See "Defining a Setting in Parent-Child Relationships".
TMS_ACTION_APPROVAL_REQUIRED: If set to N, users with this setting in their profile can assign Answerable actions directly, without assigning an Internal Action for approval, regardless of the Action approval setting for the dictionary/domain combination. This setting is a child key for TMS_PROCESS_DICTIONARY.
Note:
A setting of Y is not supported. (You can save the setting Y, but it will not have any effect.)TMS_CURRENT_DICTIONARY: Within the selected domain, the dictionary that is selected for your profile by default. This setting is a child key for TMS_CURRENT_DOMAIN.
TMS_CURRENT_EXT_VALUE_1 … 8: Within the selected external system, these eight settings determine the default values for each of the eight external system fields in the External System tab of the Omission Filter.
TMS_CURRENT_INSTANCE: Within the selected external system, the default source database in the External System tab of the Omission Filter.
TMS_CURRENT_OMIS_STATUS: Within the selected external system, the default omission status. This setting populates the Omission Status field in the Actions tab. No LOV is available for this field, so make sure the omission status you enter as the default matches the status required in the Filter window.
TMS_DSI_CURRENT_INSTANCE: Within the selected DSI external system, the default Database ID; enter the most frequently used remote database or leave blank. The list of values displays the name as well as the ID of each registered remote database.
TMS_DSI_CURRENT_X_AREA: This is a child key of the TMS_DSI_CURRENT_INSTANCE child key. For the database chosen as the default current instance, enter the ID of the most frequently used X Area on the remote database, if any. The list of values displays the name as well as the ID of each X Area on the selected remote database.
TMS_VTA_APPROVAL_REQUIRED: If set to N, users with this setting in their profile can create Approved VTAs directly in this dictionary (for any domain), regardless of the VTA approval setting for the dictionary/domain combination. This setting is a child key for TMS_PROCESS_DICTIONARY.
Note:
A setting of Y is not supported. (You can save the setting Y, but it will not have any effect.)TMS HTML settings control the default settings for HTML-based parts of the TMS application, such as the HTML Browser.
The parent-level settings are:
TMS_HTML_DQ_EXT_SYS: This setting controls the default value for the External System field in the HTML Browser. This setting is a parent key for TMS_HTML_DQ_EXT_SYS_QRY.
TMS_HTML_LANGUAGE: This setting controls the default value for the Action Owner field. This setting is a parent key for TMS_HTML_DICTIONARY.
The child level settings are:
TMS_HTML_DQ_EXT_SYS_QRY: Within the selected HTML external system, this setting controls which external system query is selected by default. These queries are also called groups, and appear in the Group field in the HTML Browser. This setting is a child key for TMS_HTML_DQ_EXT_SYS.
TMS_HTML_DICTIONARY: Within the selected HTML language, the dictionary that is selected for your profile by default. This setting is a child key for TMS_HTML_LANGUAGE.
The Settings tab enables you to define the default settings values for a profile. All settings are grouped hierarchically by their Top External Area (Top X Area), which describes what part of the application they control. The Top External Areas are OPA, TMS Forms, and TMS HTML.
Some settings also have parent-child relationships, where the child setting depends on the selected value of the parent. For example, the TMS Forms setting TMS_CURRENT_DOMAIN is a parent key for the child key TMS_CURRENT_DICTIONARY. While you can use TMS_CURRENT_DOMAIN to define which domain is selected by default for your profile, you can specify for non-default domains which dictionary is selected by default when you switch to that domain.
This section includes the following topics:
This section describes how to define which settings to use for a particular profile. A profile must exist in the database before you can define its settings; See "Defining and Maintaining Profiles".
This section describes how to define values for settings that are not part of parent-child relationships. See "Defining a Setting in Parent-Child Relationships" for more information about that process.
To define a setting for a profile:
From the Definition menu, select Maintain Settings. The Maintain Settings window opens.
From the Profile list, choose the profile in which you want to define settings.
Choose the Top External System Area from the Top X Area field. Top External System Areas group together the settings by application area: you can choose OPA, TMS Forms, and TMS HTML.
Your choice of External System Area populates the values in the Settings Key field.
Choose the setting that you want to define from the list.
The detail fields under the Extend Type field provide more information about the value or default value, but only in cases where the value or default value is not descriptive by itself. The above example for Current Domain uses the domain ID as its value, so the detail fields display the Domain Short Name.
Enter the value for the setting, or choose a value if an LOV exists. The Define Settings window displays default settings values for each setting key in the Default Value field.
Extend Type currently has no effect in TMS.
Click Set Default. TMS saves this default value for this setting.
In cases where a setting has one or more child settings that are dependent on it, you can use the child setting to establish a default value for every parent setting choice. For example, the Domain setting has the Dictionary setting as a child. You can establish a default Dictionary setting for each domain value in the database. When you choose a domain in the application, TMS will default the dictionary to the one specified for your setting for the selected domain.
To define a child setting:
Select the Profile and External Area that contain the parent and child key you want to define.
From the Setting Key field, choose the child key's parent.
Choose the parent key's value. You can specify the default child key setting for any parent key value, whether or not the value is the parent key's default.
From the Child Key field, choose the child key for which you want to create defaults.
TMS populates the Setting Key field with your selected child key, and displays the information about its parent key and parent key value.
Enter the value for the child key for this parent setting. A list of values may be available when you click in the field.
Click Set Default. TMS will use this default setting for the child key setting whenever you select this parent key value.
You can return to the parent settings level by clicking the Top Level button.
Profiles are the basis for creating default settings. By default, TMS includes the default Oracle Profile and a default Company Profile. You can use the Profiles tab to add, modify, and delete profiles.
To add a new profile, insert a row and enter a display name and a description. The display name appears in the Settings and User Profiles tabs.
To delete a custom profile (that is, one other than the Oracle or Company Profiles), select its row and delete the record. TMS prompts you to confirm the deletion; click Yes to complete the profile deletion. You cannot delete the Oracle or Company Settings profiles.
You can also change the profile's display name or description at any time.
The User Profiles tab displays user/profile combinations, and enables you to assign profiles to (or remove profiles from) users, and to modify a user profile. Because you can assign multiple profiles to a user, the User Profile determines the relative precedence of these profiles.
This tab is also convenient for assigning a profile to all members of a group.
To add a profile to a user, and set its Search Order Number:
Insert a record.
Choose the profile to which you want to add the user from the LOV.
Enter the user's OPS$ user name. It must match exactly, and no LOV is available.
Enter a Search Order Number. TMS checks lower numbers earlier when determining which profile's values to use. You can always adjust a user's overall search order by following the instructions in "Configuring a User's Profile Search Order".
Save.
Search Order determines the hierarchy of profiles for a particular user. TMS first consults the profile with the lowest Search Order value and implements the default values it specifies. The system then proceeds through the remaining profiles in ascending order by Search Order value, implementing any defaults that have not yet been set for this session.
To configure a user's profile Search Order:
Query for the user. The window displays a row for each group to which that user belongs, with a Search Order specified for each.
Rank the profiles by updating numbers for each row. The lower the Search Order Number, the earlier TMS will consult this profile for this user. Each Search Order Number must be unique for a user.
Save.
This section includes the following topics:
Reference codelists provide a body of information for TMS forms and processes, which use the codelist values to create default settings, populate lists of values, and control some aspects of TMS data processing. The values and settings are defined in TMS databases, and can usually be overridden for a more specific situation somewhere else in the system. You cannot delete reference codelists or their values, but you can set one or more values or a reference codelist itself to Inactive so it will have no effect in TMS.
For example, many TMS forms enable you to perform simple text queries as well as queries that use the Oracle Context Server. In these forms, you can choose which of these query options you want by selecting SIMPLE or CONTEXT in the Query Type field. These two values are provided in a TMS installation reference codelist, TMS_QUERY_TYPE.
There are two types of reference codelists in TMS. If you have a single instance of TMS, set values for both types.
Installation reference codelist values are set on the master instance and replicated to all the sites in a TMS installation. See "TMS_CONFIGURATION" and "Other Installation-wide Codelists".
Local reference codelists are specific to each site within the company. Local codelists control the Document Repository, which powers document searches in the HTML Browser, and Disconnected System Integration settings. See "Local Codelists".
To integrate TMS with Oracle Clinical, you must set three reference codelists in Oracle Clinical; see "Setting Integration Reference Codelist Values".
When TMS is integrated with Oracle Clinical, TMS' reference codelist replication is automatically disabled and Oracle Clinical takes over that function.
If you are using TMS separately from Oracle Clinical, TMS must use a batch job to replicate reference codelist information in a global environment; from a slave database, use the Synchronize Reference Codelists job under the Definition menu for this purpose.
If you are using the Disconnected System Integration feature of TMS, see "Setting DSI Preferences with Reference Codelist Settings".
You can edit installation and local codelist settings using two windows under the Definition branch: Installation Reference Codelists and Local Reference Codelists, respectively.
With the exception of the local codelist WEB_DOCUMENT_GROUPS, TMS populates all of the installation and local codelists. As a result, most of the work you do will be in changing values in these codelists to customize your TMS installation.
For WEB_DOCUMENT_GROUPS, you have to create all of the values you want to use as categories for your Document Servers in the Document Repository. See "Setting Categories for Web Document Groups" for more information.
To edit a reference codelist:
Navigate to the Definition menu and click either Installation Reference Codelists or Local Reference Codelists, depending on the codelist you want to edit. The window opens in Query mode.
In the Name field, query for the codelist that you want to edit. TMS displays the specific codes for the selected codelist in rows in the lower part of the window.
Define the codes in the lower part of the window. For each row in the lower part of the window, define the following:
The short value for this code. If you are defining a code for all External Documents, choose EXT or EXTERNAL as the short value.
The long value for the code. If you are defining a code for all External Documents, you might want to set this value to Ext. or External.
Active? If selected, this codelist value will appear in lists that use this codelist for an LOV. If not selected, this value will not appear.
Default? This box has no effect in TMS.
Description A description of the purpose or effect of the setting.
Save.
TMS includes the following installation reference codelists:
TMS includes the following local reference codelists:
TMS_CONFIGURATION provides a list of values and behaviors that you can set for the application. The Short Value column provides a short name for the value or behavior. The Long Value column is enterable, and you can accept the value provided or modify it. If you select Active?, the value becomes valid in the system.
There is no default value for TMS_CONFIGURATION, so selecting Default? does not change the behavior of this reference codelist.
This section provides additional descriptions of TMS_CONFIGURATION values and the features they drive in TMS. See also "Changing TMS_CONFIGURATION Settings After Data Has Been Processed". The values are:
Note:
*The settings followed by asterisks (*) above help determine the way TMS processes source terms and omissions. See "Changing TMS_CONFIGURATION Settings After Data Has Been Processed".This setting controls the default behavior of the Global setting in the Maintain VT Omissions window, which is in turn used to classify a VTA as being available globally or specific to a particular domain.
If Y, in the Maintain VT Omissions window TMS will create VTAs as Global by default. If N, in this window TMS will create VTAs as Domain-specific by default.
When you manually create a Global VTA (that is, create a Global VTA by means other than Synchronization), this setting dictates the default approval status of the Global VTA. If Y, TMS creates global VTAs as Nonapproved by default. If N, TMS creates global VTAs as Approved by default. See "Approved and Nonapproved VTAs" for further information.
Note:
When TMS creates a VTA automatically by Synchronization, the system does not refer to this setting.This setting determines the default value of the Approval Required? flag in the Define Domain Dictionaries window. If Y, the default setting is checked; if N, the default setting is unchecked. Users can change the value for any particular domain. See "Creating Domains and Assigning Dictionaries to Domains" for further information.
If N, a term that matches a Nonapproved VTA will generate an omission in TMS with Search = 'Nonapproved VTA' and a discrepancy in Oracle Clinical.
If Y, such a term will classify in TMS.
If Y, users can edit external terms from TMS windows under the Repository Maintenance menu. If N, external terms are read-only in these windows.
If Y, TMS hides named relations in the Maintain Repository Data and Browse Repository Data windows. If N, these windows display named relations. You might want to suppress named relations if you only use strong dictionaries in your TMS environment.
This setting controls the default behavior of the All Versions? box in the Maintain Informative Notes window accessed from the Repository Authoring window under the Repository Maintenance menu. If Y, this box defaults to selected; if N, it defaults to deselected.
WRKFLWINFALLVSN controls the default behavior only. You can still override the default and select All Versions? to make a workflow Informative Note apply to all versions, or clear it to make the note version-specific.
This setting controls the default status of the Appr? (or Approved?) box for verbatim terms you create in either Maintain Repository Data or Repository Authoring. If Y, this box will be selected by default for each verbatim term you create while the window is open. If N, this box will be deselected while the window is open.
VTAAPPRFLAG controls only the default status of the Appr? box. You can still override this default.
This setting controls the default status of the Appr? (or Approved?) box for dictionary terms you create in either Maintain Repository Data or Repository Authoring. If Y, this box will be selected by default for each dictionary term you create while the window is open. If N, this box will be deselected while the window is open.
DRAPPRFLAG controls only the default status of the Appr? box. You can still override the default.
(Classify VT Omissions Window Clear Comment) If Y, TMS clears the Comment field in the Classify VT Omissions window when you classify a verbatim term. If N, TMS retains the original comment, which you can edit before you commit your classification change to the database.
(Classify VT Omissions Window Clear Action) If Y, TMS clears any Action associated with a verbatim term after you apply an Action to an omission. If N, TMS does not clear the Action.
(Autocoding Process Creates Global VTAs) If AUTOGLOVTAS is Y, and ALLOWGLOVTAS is Y, the autocoding process will create Global VTAs. If AUTOGLOVTAS is N (but ALLOWGLOVTAS is still Y), autocoding creates Domain VTAs, but you can manually create Global VTAs.
If Y, TMS will refresh materialized views during Synchronization.
The Filter windows in TMS use materialized views to keep external system data up-to-date. Refreshing the materialized views can be time-consuming, so if you do not rely on external system data in Filter windows, you might want to choose N for this setting. See "Controlling the Use of Materialized Views".
If Y, TMS will display advanced dictionary features, such as the Object Classification? box in the Define Dictionaries window. If you do not use the advanced dictionary features, you might want to choose N for this setting.
This codelist setting enables you to control where the system saves the comments you create for terms. If Y, the system saves comments in the discrepancy_entries.internal_comment column. If N, the system saves comments in the discrepancy_entries.comment column. The default value is Y.
The difference is significant to Oracle Clinical Discrepancy Management, because internal comments appear in some reports and Data Clarification Forms (DCFs), while regular comments do not. If you prefer to hide these non-internal comments from DCFs and other reports, set OCDISCINTCOMM to N.
Enter the number of hours, if any, you want a user to have to fix a classification mistake he or she has made. When the long value is greater than zero, users can change classifications they have made in the Reclassify Verbatim Terms window, within the number of hours in the Long Value field, even if they do not have the normal reclassification privilege. The system displays only classifications created by the user logged into the system.
This setting determines the default value of the Action Appr Reqd? flag in the Define Domain Dictionaries window. If Y, the default setting is checked; if N, the default setting is unchecked. Users can change the value for any particular domain. See "Creating Domains and Assigning Dictionaries to Domains" for further information.
If the long value for short value DEALLOC is set to Y, any user can deallocate tasks from him or herself but cannot reallocate tasks to other users. If set to N, any user can reallocate tasks from him or herself to other users.
Note:
Users with the TMS_ALLOCATE_PRIV role can reallocate tasks regardless of this reference codelist setting.This setting determines the default value of the Non Appr DT field in the Define Domain Dictionaries window. If the long value is NONE, the default value for the Non Appr DT field is NONE. If the long value is VTA, the default value of the field is VTA. See "Creating Domains and Assigning Dictionaries to Domains" for further information.
Some of the settings for the TMS_CONFIGURATION reference codelist (CREATEGLOBALVTA, GLOVTAAPPRREQD, DOMVTAAPPRREQD, NONAPPRVTAUSED, ALLOWGLOVTAS, and AUTOGLOVTAS) help determine the way TMS processes source terms and omissions in fully integrated external systems, and omissions in partially integrated external systems.
If you change one of these settings after source terms and omissions have already been processed, the system does not automatically reprocess old data using the new setting. You must use the Force Rederivation job to mark study omissions (and source terms, in fully integrated external systems) for processing during the next Batch Validation or equivalent job.
If you are using TMS with Oracle Clinical, you can call the Force Rederivation job by selecting Oracle Clinical's Plan menu, choosing TMS Domains, then selecting Studies, Domain Elements, and then Force Rederivation. Alternatively, you could call through the API, using the procedure ocl_tms_pack.SetLastTMSDerivTS (see the Oracle Thesaurus Management System Technical Reference Manual for details). You must then run Oracle Clinical Batch Validation.
If you are using a different external system, you must mark records for reprocessing and then run the equivalent of Batch Validation to actually reprocess them.
Descriptions of the TMS installation-wide codelists, other than the TMS_CONFIGURATION codelist, follow.
Values in this codelist populate the Language field in the Define Dictionaries window. English is the default dictionary language.
TMS_QUERY_TYPE populates the LOV in the Query field for several forms in TMS. The default value, STANDARD, provides a standard Oracle query, while the CONTEXT value enables you to use the Oracle interMedia option.
TMS_SOURCE_MAT_VIEWS controls whether materialized views or regular views are used to populates the LOVs for each external system value in the Filter window, which launches from Reclassify Verbatim Terms and Approve VTAs. Oracle recommends using materialized views for Values 1-3 when using TMS with Oracle Clinical. See "Controlling the Use of Materialized Views".
Set a value for VTOs (omissions), VTAs (here, unapproved VTAs only), and ACTs (here, unapproved Action assignments):
N (No Allocation). If set to N, Task Allocation is not available to omissions, unapproved VTAs, or unapproved Action assignments.
D (Direct Allocation). If set to D, TMS performs Direct Allocation as soon as an omission, unapproved VTA, or unapproved Action assignment is created. See "Direct Allocation".
P (Pool Allocation). If set to P, TMS effectively puts omissions, unapproved VTAs, or unapproved Action assignments in a pool. They can then be allocated either manually or by invoking a pooled algorithm. "Manual Pool Allocation" and "Automatic Pool Allocation".
Note:
The Task Allocation menu item does not appear in the TMS Navigator panel unless the long value for at least one of the short values—VTO, VTA, or ACT—is set to either D or P. If all are set to N, Task Allocation does not appear in the Navigator.TMS includes the following local reference codelists.
The local reference codelist TMS_DSI contains parameters whose settings determine important aspects of DSI behavior; see "Setting DSI Preferences with Reference Codelist Settings".
TMS refers to settings in this codelist to configure several aspects of the Document Repository searches in the HTML Browser. Table 3-1 describes the codes, the parts of the application which they control, and default settings.
Table 3-1 WEB_DOCUMENT_CONFIG Settings
| Setting | Long Value | Description |
|---|---|---|
|
WEBDOCSETUP |
N |
Equal to N until you create and populate the Document Index; afterwards, this value is automatically switched to Y. When equal to Y, TMS enables you to perform Document Repository Searches in the HTML Browser. Additionally, if this value is set to N, TMS does not display the Research tab. |
|
DOCSCANRFINX |
N |
If Y, TMS will call the Refresh Document Index job after the Refresh Document Servers job completes. If N, TMS will not call the Index job when the Servers job completes. N is the default setting. |
You can populate this codelist with categories for the documents you retrieve using Document Repository searches in the HTML Browser. For specific instructions on setting these values and suggested groups, see "Setting Categories for Web Document Groups".
This section includes the following topics:
TMS is designed to be used in a global environment, with a single master instance linked to multiple slave, or local, instances. All definition and dictionary maintenance functions must be performed at the master instance, but classification is allowed at any instance (see "Performing Manual Classification at All Instances"). The master instance must be running to allow classification and browsing on a local instance.
TMS uses symmetric replication to replicate data among locations. See "Symmetric Replication".
Note:
If you are using TMS with Oracle Clinical in a distributed environment, the TMS master instance must be on the same location as the Oracle Clinical Global Library instance, and you must use symmetric replication in Oracle Clinical as well as TMS.If you are using TMS in a distributed environment without Oracle Clinical, you need to use a batch job to replicate installation reference codelist settings. The TMS batch job Synchronize Reference Codelists appears under the Definition menu on slave sites.
Note:
If you are using TMS with Oracle clinical in a distributed environment, TMS' reference codelist replication is automatically disabled and Oracle Clinical takes over that function.To synchronize reference codelist settings, on each local instance:
From the Definition menu, select Jobs, then choose Synchronize Reference Codelists. The Synchronize Reference Codelists batch job window appears. There are no parameters to enter.
Use the runner icons in the toolbar to save and retrieve parameter sets as necessary, submit the job, and monitor its progress.
See "Setting Up and Running Reports and Other Batch Jobs" for further information.
To add an instance, you must install the new database, create new database objects, import data from the master, and do a few other tasks; see instructions in the Oracle Thesaurus Management System Installation Guide.
You must run Synchronization on the new instance before you try to classify any terms. You should also schedule Synchronization to run regularly on the new instance. See "Synchronizing Dictionary Data".
TMS allows each instance to classify omissions, though the master site serves as the central repository behind the scenes.
Automatic classifications are propagated to all instances during symmetric replication. Manual classifications and Actions are done interactively in real time at the master and the classifying instance, and are propagated to other instances during replication.
Reclassification can occur at the master site only, and high-level classification at the local sites only.
When you run Autoclassification at any instance, either independently or, more typically, as part of Oracle Clinical Batch Validation or the equivalent job for a different external system, the job looks for direct matches for source terms in the dictionary's classification level(s).
If Autoclassification finds a direct match in the VTA level, it puts the source term immediately into the Source Terms table with the ID of the VTA (dict_content_id).
If Autoclassification finds a direct match in the DT classification level, it puts the source term in the Omissions table with a temporary classification ID (dict_content_tmp_id). (The Omissions table is globally maintained; see Symmetric Replication.) The next Synchronization on the master instance creates a new VTA and VTA ID (dict_content_id) for the source term. Each slave instance receives the omission and its new dict_content_id during the next replication; each slave instance, including the one where it was originally temporarily classified, must run Synchronization to move the source term into the Source Terms table with its classification (dict_content_id).
If the classification occurs on the master instance in a replicated environment, it gets a temporary ID there too, until Synchronization. (If the master instance is not in a replicated environment, Autoclassification puts the source term directly into the Source Terms table with a dict_content_id.
If Autoclassification does not find a direct match in any classification level, it puts the source term in the Omissions table as an omission (without either a dict_content_id or a dict_content_temp_id). The term must be manually classified, or an Action applied to it.
No conflicts should arise from Autoclassification, even if more than one instance processes the same new source term at the same time, because it uses direct matches only. The dict_content_id is simply the ID of the term to which the source term is classified, so both slave instances assign the same dict_content_id to source terms that are a direct match.
TMS allows manual classification (or Action application) to occur simultaneously at the master instance and all local instances on all omissions.
When a user manually classifies a term at a slave instance, the system calls a package to immediately create the classification at the master instance. During the next replication, the source term and its VTA are propagated to all instances and the omission is updated. During the next Synchronization, the source term is moved out of the Omissions table and into the Source Terms table (see "Synchronizing Dictionary Data").
Note:
To perform manual classification at a slave instance, the master instance must be running.During manual classification, conflicts are kept to a minimum because the process is centralized in the master instance. However, it is possible for two or more sites to collect the same term during the same period between replication jobs, and handle it differently. These conflicts are resolved at the master instance.
The following types of conflicts are resolved interactively in the user interface:
If two sites classify the same term differently, the master uses the classification with the earlier timestamp and returns an error to the other site when the later classification is attempted.
If two sites apply a different Action to the same term, the master uses the Action with the earlier timestamp, and returns an error to the other site when the later Action application is attempted.
The following types of conflicts are resolved during the next replication. The master resolves the conflict according to the rules below and propagates the classification or Action to all sites.
If one site applies an Action to a term, and another site classifies the same term, the master uses the classification, not the Action.
If a dictionary term is added on the master site that provides a direct match to a verbatim term but conflicts with an existing local classification, the master overwrites the local classification with a classification to the direct-match dictionary term.
If one site changes an Action's ownership (from Oracle Clinical to TMS, for example) and another site applies a new Action to the same term, the master uses the Action with the changed owner.
If one site assigns a Discrepancy Message to a term and another assigns a Global Action to the same term, the master uses the Discrepancy Message.
If two sites apply different Discrepancy Messages to the same term, the master uses whichever Action is processed first during replication. The first Action processed is not necessarily the one with the earlier timestamp. It is not possible to predict which one will be used.
Symmetric replication uses materialized views to maintain data consistency across multiple TMS instances in a distributed environment.
During installation you use scripts to create TMS tables on each slave instance and then export data from the master to each slave instance. You then start symmetric replication (see the Oracle Thesaurus Management System Installation Guide).
After installation, symmetric replication runs automatically behind the scenes to replicate data changes among TMS instances. First, the master instance pulls data changes from all the slave instances. Then the slave instances pull the cumulative changes from the master.
Note:
When an omission is created on a slave instance—through Oracle Clinical Batch Validation or a similar process for a different external source data system—the omission is not available to a user at the slave instance in the Classify VT Omission window until replication has been run.TMS tables fall into several categories for replication:
All TMS tables used in definition are maintained on the master only, but their data is replicated to slave instances in a read-only state.
Several tables are actually maintained at the master instance, but users at slave instances appear to be able to change data in these tables. Changes are made on the master in real time. The changes are propagated to other instances during replication. Tables in this category include the dictionary contents and relations tables and Informative Notes tables.
The changes allowed from slave instances are allowed only during classification, and include creating VTAs and VTA IDs, and maintaining VTA Workflow Informative Notes.
The Omissions and Actions tables are maintained globally. That is, any instance can classify any omission or apply an Action to any omission owned by TMS (not the external system). This process works differently depending on whether the classification is automatic or manual. During replication, each slave instance's automatic classifications are replicated to the master and then replicated from the master to the slave instances. Users manually classify omissions and apply Actions to omissions interactively. See "Using Autoclassification at Each Instance" and "Performing Manual Classification at All Instances".
Some tables are maintained locally only and are never replicated. These tables include Source Terms (which stores locally collected source terms only), High-level Classifications, Domain Elements, Instance Dictionaries, document-related tables, and error log tables.
Some tables are maintained at the master only and are never replicated. These are the "predict" tables used in the activation of dictionary terms and relations.
Note:
Information on managing replicated databases is available in the Oracle manual Advanced Replication.This section includes the following topics:
The TMS Synchronization batch job runs on individual TMS instances. It checks for changes in the TMS repository that impact the Omissions and Source Terms tables and:
Updates records in those tables
Marks the Update flag for the same records so that they are reprocessed during the next data exchange between TMS and the external system (Batch Validation in Oracle Clinical)
In a distributed environment, omissions can be classified at any instance (see "Performing Classification at All Instances"). Therefore, you must run Synchronization locally to update the Source Terms table with changes made at other sites.
If you have TMS integrated fully or partially with an external source data system, you must run Synchronization. TMS Synchronization is included in Oracle Clinical Batch Validation when the two systems are integrated.
If you are using TMS as a look-up system only, without integration to an external source data system (such as Oracle Clinical), you do not need to run Synchronization.
Oracle recommends that you run Synchronization at least five times during the business day at each site. You should also run Synchronization before and after batch jobs that exchange information between TMS and an external system. When TMS is integrated with Oracle Clinical, this happens automatically during Batch Validation.
The Omissions table contains source terms that Autoclassification could not classify. The Source Terms table includes all locally collected, classified source terms and the classification (VTA ID; dict_content_id) for each one. When an omission is classified, the Synchronization job moves the source term from the Omissions table to the Source Terms table, associated with its classification. If a VTA is changed at any point, Synchronization changes the VTA ID in the Source Terms table.
The following types of changes require synchronization with the Source Terms table:
Classifying source term omissions
Declassifying and reclassifying verbatim terms
Approving and unapproving VTAs
Loading a new dictionary (to mark the dictionary for future processing)
Loading a new dictionary version (to mark the dictionary version and its source terms and omissions for future processing)
Changes to Informative Notes that are derived to the external system
In addition, if TMS is integrated with an external system, the following changes to source terms in the external system must be synchronized in TMS:
Definitional changes such as question definition changes or mapping a study or project to a different domain in Oracle Clinical
Deletion of source terms in the source system (Oracle Clinical responses)
Synchronization processes only locally owned data. Synchronization does not process omissions created at a different instance and replicated; these omissions are owned by the instance where they were created.
Synchronization runs on data imported using the TMS DSI feature; because the systems are not integrated, the importing instance owns the data.
Synchronization always includes two phases, pre-synchronization and post-synchronization.
Pre-synchronization Pre-synchronization runs first. It updates records as outlined "Data Processed During Synchronization" and sets the Update flag to Y so that records will be updated in the external system during the next data exchange (Batch Validation in Oracle Clinical).
Post-synchronization Post-synchronization runs last. It refreshes materialized views if the TMS_CONFIGURATION reference codelist value SYNCREFRESHMV is set to Y (see "SYNCREFRESHMV").
In addition, when run at the master site, it executes the Purge Classified VT Omissions batch job (see "Purging Classified Omissions from the Omissions Table").
If you choose not to refresh materialized views, which can take a long time (see "Controlling the Use of Materialized Views") and the Synchronization job is not running on the master site, the post-synchronization phase is not executed.
External System Integration If TMS is integrated with an external source data system, additional processing occurs between these two phases during data exchange between the two systems. The data exchange job must:
Run full autocode on all source terms that have been changed since the last data exchange and on all records in the Source Terms and Omissions tables whose Update flag is checked
Reset the Update flag on all processed records to N
Oracle Clinical Batch Validation is predefined to do both.
The batch processing unit (a study in Oracle Clinical) is called an X Area in TMS. The following indexes use the X Area to give fast access to source terms and omissions that need to be processed:
TMS_SOURCE_TERMS_BI3
TMS_VT_OMISSIONS_BI1
Both indexes include the following columns: NONUNIQUE X_AREA, NONUNIQUE DEF_INTEGRATION_KEY, NONUNIQUE UPDATE_FLAG.
Note:
Although Batch Validation runs on only a single study, or TMS X Area, Synchronization always runs on all TMS data, even when run during Batch Validation.To run Synchronization:
From the Definition menu, select Jobs, then Synchronize Dictionary Data. The Synchronization batch job window appears. There are no parameters to enter.
Use the runner icons in the toolbar to save and retrieve parameter sets as necessary, submit the job, and monitor its progress.
See "Setting Up and Running Reports and Other Batch Jobs" for further information.
TMS can use materialized views to populate the lists of values for external system columns in the Filter window of Reclassify Verbatim Terms and Approve VTAs. Using materialized views accelerates populating many of these LOVs, but in databases with a high data volume, refreshing materialized views during Synchronization can be too slow.
If the materialized views refresh during Synchronization is slowing Synchronization at your database, you have two options:
You can reduce the number of external system columns that rely on materialized views, switching some or all of them to regular views. To perform this switch, follow the steps in "Choosing Materialized or Regular Views for Each External System Value", then create the new views by "Creating Source Term Views".
You can remove the materialized views refresh from the Synchronization process. To de-couple this refresh from Synchronization, perform the steps in "Including the Materialized Views Refresh in the Synchronization Process". If you use materialized views for any external system values, and you have made this refresh process independent of Synchronization, you must still perform the refresh periodically. See "Refreshing Source Term Materialized Views".
The installation reference codelist TMS_SOURCE_MAT_VIEWS controls whether regular views or materialized views are used to populate the list of values for external system values in the Filter window. Each value in the codelist controls the view behavior of one external system field: for example, setting the long value of the codelist value MV1 to Y will make TMS use a materialized view to populate the list of values for the external value 1 in these Filter windows.
By default, TMS_SOURCE_MAT_VIEWS specifies that materialized views be created for external values 1 to 5, and regular views for external values 6 to 8.
Whenever any of the values in TMS_SOURCE_MAT_VIEWS are changed, you must run the Create Source Terms Views batch job. See "Creating Source Term Views".
To change the view settings for an external system value:
Open the Installation Reference Codelists window. (From the Definition menu, select Installation Reference Codelists.)
Query for the TMS_SOURCE_MAT_VIEWS codelist.
Update the long value for each external system value that you want to change.
Save.
Whenever you change any of the values in the TMS_SOURCE_MAT_VIEWS reference codelist, TMS must create a new view for each external system value you changed. Run the Create Source Terms Views batch job to create the materialized or regular views that your change requires.
To run this job from the user interface:
From the Definition menu, select Jobs, then choose Create Source Terms Views.
To run this job from a SQL*Plus prompt, execute the following API call:
tms_user_data_admin.configSTMatViews
You can control whether TMS refreshes materialized views during the Synchronization process by changing the reference codelist value SYNCREFRESHMV in the TMS_CONFIGURATION reference codelist. If this setting is Y, the materialized views refresh will be included in Synchronization.
If you remove the materialized views refresh from Synchronization, you must periodically run the Refresh Source Term Materialized Views batch job to refresh them manually. See "Refreshing Source Term Materialized Views".
To change the inclusion status of materialized views in Synchronization:
Open the Maintain Installation Codelists window. (From the Definition menu, select Installation Reference Codelists.)
Query for the TMS_CONFIGURATION reference codelist.
Scroll down to the SYNCREFRESHMV row, and change its long value setting. A long value of Y includes the materialized views refresh in Synchronization; N removes this refresh from Synchronization.
Save. TMS will either couple or de-couple the materialized views refresh and the Synchronization process.
If you do not refresh the materialized views as part of Synchronization, you must refresh them periodically by running the Refresh Source Term Materialized Views batch job.
To run this job from the user interface:
From the Definition menu, select Jobs, then select Refresh Source Term Mat. Views.
To run this job from a SQL*Plus prompt, execute the following API call:
tms_user_synchronization.RefreshMviews
Context searches enable you to be more flexible in your queries. You can perform context searches for word fragments, terms that share a common root, terms that sound similar, or terms that have the same meaning. For more information on context searches, see "Entering a Context Query".
By default, TMS is configured to perform context searches for English-language dictionaries only. However, because TMS indexes information in a multi-lexer, a data structure that can store information in multiple languages; you can configure TMS to allow context searches in other languages.
To add a new language to the Context Server Index:
From the Install directory, open the following script in a text editor:
tms\database\tmscincontextinx.sql
This script includes sample commands for adding Japanese, Danish, or German to the Context Server Index. If you want to add one or more of these languages to your index, copy the appropriate lines to a buffer.
If you want to add a different language, modify the lines to suit the language you want. For more information, see the System-Defined Preferences section of the Indexing chapter in the Oracle Text Reference manual (part number A96518).
Start a SQL*Plus session as TMS.
Run the copied or edited lines.
Refresh the Context Server Index by running the job from the Definition menu. See "Refreshing the Context Server Index".
When you insert new dictionary terms or VTAs into the TMS repository, the Context Server cannot find them in a query until you refresh the Context Server Index. Oracle recommends that you schedule this refresh as a batch job running as often as is appropriate for your TMS installation.
You can refresh the Context Server Index by running the Refresh Context Server Index batch job.
To refresh the Context Server Index:
From the Definition menu, select Jobs, then Refresh Context Server Index. The Refresh Context Server Index batch job window appears. There are no parameters to enter.
Use the runner icons in the toolbar to save and retrieve parameter sets as necessary, submit the job, and monitor its progress.
See "Setting Up and Running Reports and Other Batch Jobs" for further information.
TMS automatically runs the Analyze Tables batch job after Activation to optimize TMS performance. You can also schedule this batch job to run periodically; from the Definition menu, select Jobs, then Analyze Tables, and specify the batch job's parameters.
See "Setting Up and Running Reports and Other Batch Jobs" for further information.
A conflict can arise when users delete omissions in distributed TMS environments. If a user deletes an omission at one site, then another user updates the same omission at another site, the Oracle Symmetric Replication Packages return an error ("ORA-1403 no-data-found") and the deletion does not propagate through the TMS sites.
To avoid delete conflicts like this one, TMS now deletes omissions in two stages:
When you choose to delete an omission from your site, TMS performs a "logical deletion" of that omission's row in the tms_vt_omissions table. Logical deletions do not remove rows from this table, but do flag these rows for later deletion from the table.
The Definition batch job Purge Classified omissions physically deletes these marked rows from the tms_vt_omissions table. Only users who have the tms_define_priv role can run this procedure.
The Purge Classified omissions job runs on the master site only as part of symmetric replication. TMS follows this logical deletion structure whether you use symmetric replication or not. We strongly recommend that you run this procedure weekly for your TMS installation. Running the procedure at one site will purge classified omissions from that site only. TMS automatically runs this job as part of Synchronization when you run Synchronization from the master site.
If you are getting an error message like "Java exception" followed by another message like "http://127.0.0.1/opaxdo/getXdoReport not found" when you try to run a TMS report, you may want to modify the setting of registry variable OPA_LOCAL_MT_URL. This variable is used to redirect the server to the opaxdo servlet to get reports. When not defined, http://127.0.0.1 is used as default value.
Depending on the settings on middle tier, you may encounter this problem. To fix it, add a port number to the registry variable OPA_LOCAL_MT_URL value on the middle tier; for example, http://127.0.0.1:7777.
To confirm that the path in the registry variable is correct, submit the value such as http://127.0.0.1:7777 (or, without port, http://127.0.0.1) from a browser on the middle tier. If the registry value is correct, you receive the message "Got Request."
|
 Copyright © 1999, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
