| 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 new features and enhancements included in recent releases of Oracle Thesaurus Management System (TMS). All changes are included in the current release.
Release 4.6.2 includes upgrades to the technology stack, leveraging more up-to-date capabilities and tools and alleviating end-of-support windows for legacy components. The technology stack is the same as for Oracle Clinical 4.6.2, facilitating integration between the two systems.
Release 4.6.1 includes the following new features:
Classification to Nonapproved Dictionary Terms Can Be Allowed
Filtering and Multirecord Selection for Task Allocation by Term
New Informative Note Attribute for Use in RDC Special Listings
You can allow classifying terms to nonapproved dictionary terms in selected domains. For example, in a domain used for an active study you can prevent classification to nonapproved terms, but in a domain used for post-marketing surveillance, you can allow classification to nonapproved terms to prevent unnecessary reclassification after a dictionary upgrade. Global VTAs cannot be linked to nonapproved dictionary terms.
This change affects many features and is documented in each relevant section:
Note:
If you are already using custom search objects and now start allowing classification to nonapproved dictionary terms in some domain/dictionary combinations, you may need to modify your algorithm. The sample Domain Match search object now contains code you can use as a model; see "Sample Domain Match Search Object".Modifying Repository Data in the Maintain Repository Data Window
Task Allocation now includes a Filter button and standard TMS filter functionality to limit the terms displayed. In addition, you can select multiple terms at the same time using either Shift+Click or Ctrl+Click to assign the terms. See "Using Manual Allocation by Term".
The Oracle Clinical Remote Data Capture (RDC) Option Release 4.5.3 and above has a Special Listings feature that displays concomitant medications and adverse events for patients. This feature is available only when TMS is integrated with Oracle Clinical and displays parent questions mapped to TMS dictionaries with the question responses to all other questions in the parent question's question group that are defined as nonderived and displayed.
By default, the system displays the TMS dictionary name in the action drop-down list on the RDC Home page, Casebooks page, and elsewhere. You can change this to the text of your choice by defining a new type of Informative Note called RDC Action Text for each dictionary. The system substitutes the text you supply in the Value field of the Informative Note for the dictionary name; see "RDC Action Informative Notes".
See also "Planning Question Groups and DCMs for RDC Special Listings".
Release 4.6 includes the following new features described in the following sections:
In addition, see "Documentation Changes" for more information.
Until Release 4.6, all Actions were external. They were sent to an external source data system to convey information and request an Action on the part of an external system user. Release 4.6 introduces Internal Actions that are used inside TMS. They serve two purposes:
Internal Actions allow approving Action assignments before they are sent to the external system. You can now require approval of Action assignments for a domain and dictionary combination the same way you can require the approval of VTAs.
Internal Actions allow users to indicate that they are working on a term so that other users do not duplicate their efforts.
In addition, external Actions have been renamed: Conditional Actions are now called Answerable Actions, Never Expire Actions are now called Unanswerable Actions, and Single Term Actions are now called Discrepancy Comments.
The new windows that support this feature are Approve Action Assignments (in the Omission Management menu) and Maintain Action Assignments (in the VTA Maintenance menu).
For further information see "Defining and Using Actions" and "Approving Action Assignments".
Beginning in Release 4.6, you can explicitly allocate tasks to specific users, including classifying omissions and approving unapproved VTAs and Actions. You can use the following methods:
Direct allocation: The system allocates tasks automatically as soon as they are created.
Automatic pool allocation: The system allocates multiple tasks to one or more users at a time according to your specifications.
Manual pool allocation: You manually assign tasks to users.
Using the Filter pop-up, you can create activity lists of the omissions, unapproved VTAs, or unapproved Actions that are assigned to you and use these lists as your daily "To Do" list. If you have the necessary privileges, you can create activity lists for other users to track their progress.
Task allocation is optional. You can use activity lists to save lists of tasks that satisfy filter criteria you set, even if you are not using task allocation.
There is a new menu item called Task Allocation that includes four new windows and a new report, respectively: Maintain User Task Allocation Pools, Task Allocation by Term, Task Allocation by Quantity, Maintain Direct Allocation Error Logs, and Unfulfillable Assignments. Two new windows under Omission Management support activity lists: Activity List and Maintain Activities.
See Chapter 9, "Allocating Tasks to TMS Users" and "Setting Filters and Creating Activity Lists", "Using Activity Lists", and "Maintaining Activity Lists" for more information.
Release 4.6 introduces new term statuses and sub-statuses that track a term's process throughout its life cycle. You can see a term's current status and sub-status in the following windows:
Classify Omissions
Reclassify Verbatim Terms
Approve VTAs
VT History
Activity List
VT Simple Search (HTML Browser)
VT Advanced Search (HTML Browser)
VT Details (HTML Browser)
You can bring up a display of a term's complete status history by clicking the Status/Notes button from most of the windows listed above. In the non-browser windows you can add a note when you change a term's status. (See Chapter 10, "Omission Management" and the sections on each of the windows above.)
You can create Data Access Groups (DAGs), which allow you to selectively restrict the data users can see. As before, database roles determine which windows a user can access. DAG assignments dictate the data users can see in those windows and whether they can make changes to the data.
You can also designate a user as a superuser. Superusers can see and operate on all data and cannot belong to a DAG (the pre-4.6 behavior).
When you define a DAG you can make the following specifications:
You can specify the dictionary/domain combinations for which users in the group can see data.
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, for example, from a particular project or study.
You can specify whether users in the group can see data that originated in one or more specific external system 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 a DAG and then assign users to it. 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.
There is a new menu item called Security that supports DAGs. It includes the original, now modified, Define Users window as well as new windows Define Security Columns and Maintain DAGs. It also includes a new report, DAG and Setting Inconsistencies and a new job, Create/Drop EXT_VALUE Indexes.
See "Using Data Access Groups (DAGs) for Security".
Release 4.6 introduces dictionary Release Labeling and a new type of named relation called Release Label (RL). When you define a dictionary, you must now specify a label prefix for the dictionary. Each time you run Activation, TMS applies a Release Label to the successfully activated terms and relations in the Activation Group. The label consists of the prefix you define plus a build number that represents the number of times Activation has been run on the dictionary. For example, if you defined a label prefix of 3.0. for WHO-Drug 3.0, the system would label the first Activation Group 3.0.1; the system would label the second Activation Group 3.0.2.
When you upgrade to Release 4.6 from an earlier version of TMS, the upgrade process looks for a dictionary version-type Informative Note for each dictionary you have already defined and, if there is one, populates the label prefix with that value. For each existing virtual dictionary, the upgrade process creates a Release Label that consists of the prefix (if any) and an appended number: either 1 or, if there are more than one virtual dictionaries with no dictionary version Informative Note value (or the same value) a unique number among those virtual dictionaries. The upgrade process inserts a period/full stop (.) between the prefix and the appended number if the prefix does not already include one.
You can use named relations of type Release Label to record the relationship between a term in one dictionary or dictionary version to another, for complex changes such as term merging or term splitting that TMS cannot maintain automatically. For example, if a new release of MedDRA splits Term A into Term A and Term B, you can create a named relation of type Release Label between Term A in the older dictionary version and Term B in the newer dictionary version.
You can view term history, including Release Label named relations, in the HTML Browser. Do a search in the Terminology tab and then click the term to see the Term Details window with a Related Release Label section.
One new window supports this feature: Release Label Authoring under the Repository Maintenance menu.
See "Defining a Dictionary" for information on defining a label prefix. See "Defining Named Relations" for information on defining named relations of type Release Label. See "Using the Release Label Authoring Window" for information on creating a Release Label named relation between two terms.
In Release 4.6 you can analyze the impact that upgrading to a new version of a dictionary will have on your existing VTAs and omissions before activating it. A new job performs many of the changes you will need to make. Several reports allow you to see the changes, and a new form allows you to see changes and to make changes manually to terms and relations, including VTAs, while they are still in the predictionary tables to avoid problems during and after Activation.
There is a new menu item, Dictionary Upgrade, with a new window and several new reports and jobs.
See Chapter 8, "Upgrading to a New Dictionary Version" for more information.
Release 4.6 supports MedDRA Standardized MedDRA Queries (SMQs) with a new dictionary type called a filter dictionary and a new Informative Note type called algorithm Informative Note. In the HTML Browser you can search for source terms using MedDRA SMQs and retrieve external system information about the source terms.
The HTML Browser includes several new screens to support this feature.
See "Filter Dictionaries" and "Searching for Terms Using Filter Dictionaries" for more information.
Release 4.6 introduces the following DSI enhancements. See "Using TMS with Disconnected Systems" for further information.
New and changed Informative Notes of type Workflow associated with verbatim terms are now included in both imports and exports for both source and sponsor sites, and are synchronized across instances.
New jobs allow you to export and import data for a particular X Area from a single instance instead of all instances.
You can now exchange data between two UTF-8 databases as well as two Western European (WE) character databases. Both the sponsor and source sites must support the same character set.
DSI uses the codelist XAPPVTA at source as well as sponsor sites to control whether export files contain unapproved VTAs.
Only superusers can run DSI jobs. (We made this change to accommodate Data Access Group (DAG) security.)
Before you can set up DSI, you must initialize your instance as either a DSI source site or a DSI sponsor site.
When you define a disconnected system integration on a source instance, TMS now displays a list of values for the X Area Name. It includes all X Areas defined on the external sponsor system and the database specified in the Definitions tab.
Note:
The XML schemas required for both sponsor and source sites have changed to support these enhancements. See Appendix B, "Disconnected System Integration XML Files."For more information, see "Using TMS with Disconnected Systems".
Release 4.6 uses Oracle XML Publisher to format reports. All reports have a new appearance. In addition, you can customize the template to change the appearance of reports if you want to; see "Customizing Report Templates" for more information.
Release 4.6 includes the following new reports:
Verbatim Term Modifications Report (This report combines and replaces the three classifications reports.)
Release 4.6 expands HTML Browser functionality to complement several new features:
Filter dictionaries
Status history
Status notes
See "Searching for Terms Using Filter Dictionaries" and "Viewing VTA and Omission Status Information" for more information.
In addition, it is now possible to search for omissions as well as classified verbatim terms in the HTML Browser. You perform this action from a new Verbatim Term Status tab. See "Performing a Simple Verbatim Term Status Search" for more information.
Release 4.6 includes the following minor enhancements.
In the Classify VT Omissions window, you can now apply Informative Notes to unique occurrences of verbatim term omissions (VTOs) in a domain/dictionary combination. See "Using the Status/Notes Pop-up Window" for more information.
When you define new Informative Note attributes you must now specify one or more dictionaries within which they can be used. Then when you add an Informative Note to a term, relation, or dictionary, TMS allows you to use only Informative Note attributes that have been specified for use with the appropriate dictionary.
When you upgrade to Release 4.6 from an earlier version, the upgrade process populates the new "Applies To" field for your existing Informative Note attributes with the dictionaries with which they are currently used. If you want to use an Informative Note attribute with additional dictionaries, use the Define Dictionary Informative Note Attributes window. See "Defining Informative Note Attributes" for more information.
Due to changes required to implement Data Access Groups, you no longer create a user during dictionary loading for the purpose of loading the dictionary. You can now grant dictionary loading privileges to any user through the TMS Define User window by setting the new Load User check box to Yes. See "Defining Users" for more information.
The tmsadduser.sql script now creates a user with OPA_ADMIN privileges. This user has access to the Define Users window in the UI and can create all other user accounts.
A new user profile setting allows you to specify users who can create approved VTAs and Actions even in dictionary/domain combinations where approval is required. See "TMS_PROCESS_DICTIONARY" for more information.
Users with Reclassify or Classify privileges can now declassify verbatim terms in the Approve VTAs window. As in the Classify VT Omissions window, users with Classify privileges have a configurable period of time in which they can change their own classifications. Users with Reclassify privileges have no time limit. See "Understanding the Approve VTAs Window" for more information.
You can write a function to replace the X Area ID with a meaningful value for X Areas in reports and on screen. For Oracle Clinical, the X Area is a study and TMS now displays the study name instead of the X Area ID. If you prefer, you can write a function to display a different value for Oracle Clinical X Areas. See "Defining the External System in TMS" for more information.
The user-defined external values (and those predefined for Oracle Clinical) have been increased in size so that you can store values of up to 500 characters. The previous limit was 30 characters.
Users with browse-only privileges now do not see the Source Data icon.
We documented the new features and made the following changes to the Oracle Thesaurus Management System User's Guide:
In the chapters in the Oracle Thesaurus Management System User's Guide that correspond to menu items, reports are grouped at the end of chapters in sections with the name of each report as the section heading.
Some new windows do not have field-level online help. However, you can click the More button to see the online help for the window as a whole, including a description of each field.
The enhancements included in Release 4.5.2 relate primarily to integration with Oracle Clinical:
In addition, the Define Users window has been moved to a new location: the newly created Security menu. Therefore the TMS_DEFINE_PRIV privilege is no longer required to access the Define Users window; only OPA_ADMIN is required. The documentation in Chapter 3, "Administration" has been updated accordingly.
To allow deriving data from two dictionaries for a single term collected in Oracle Clinical, Release 4.5.2 makes two changes:
Question set parent questions can be defined as derived. Their value can be populated by an Oracle Clinical derivation procedure as necessary, including reading the value of a derived child question set question and writing it to the value of a derived parent question.
If there are derived parent question values after Oracle Clinical procedures have been executed during Batch Validation, the TMS portion of Batch Validation is run again just on those values, and TMS information is derived for their child questions during the same Batch Validation job.
This functionality may also be useful in other circumstances. See "Using a Derived Question as a Parent Question".
Until Release 4.6, if Oracle Clinical Batch Validation encountered a serious problem during the TMS processing portion, the whole Batch Validation process failed. You can now choose whether or not you want this to happen by setting a new reference codelist value in Oracle Clinical. Also, if the errors encountered during TMS processing are not serious, Batch Validation will not fail, but will display a warning.
For more information, see "OCL_STATE".
A new job is available in Oracle Clinical for running only the TMS portion of Batch Validation. See "Running Only the TMS Portion of Batch Validation".
The installation and migration of Release 4.5.2 requires a new Installer, which handles a fresh installation as well as migration from previous versions 4.5.x and above.
Release 4.5.1 included the following new features:
The Disconnected System Integration (DSI) feature provides a customized XML-based batch data load process that enables you to use TMS as a central dictionary classification tool for systems located remotely and operated by different businesses or research organizations.
DSI is designed specifically to allow a pharmaceutical company sponsoring a clinical trial that is being conducted by multiple contract research organizations (CROs), to use TMS as a central classification tool for terminology quality control. CROs send their source data to the sponsor, with contextual information (such as patient ID and document number) and preliminary classifications. The import process at the sponsor site compares the CRO's classifications to the sponsor's and enters data in the sponsor database and/or creates warnings or errors associated with faulty data. When the sponsor sends the data back to the CRO, the CRO's import process overwrites CRO classifications with those of the sponsor, if there are conflicts, and passes on any Actions created at the sponsor site for particular terms.
The sponsor instance stores all CRO source terms and contextual information, and runs TMS Synchronization on CRO data. However, the sponsor instance does not have a UI drill-down capability for CRO data, and, if the sponsor is using Oracle Clinical, OC Batch Validation does not run on CRO data.
The sponsor must use TMS. The CRO must use either TMS or another dictionary coding system that is capable of processing XML files in the required DSI structure. The external source data system feeding data into TMS can be Oracle Clinical, the Oracle Adverse Events Reporting System, or a third-party system.
For more information, see "Using TMS with Disconnected Systems".
Note:
The Disconnected System Integration feature does not support the UTF8 character set.Until Release 4.5.1, when a TMS user made a mistake classifying a verbatim term, he or she required reclassification privileges to fix the problem. In Release 4.5.1, the user has a certain number of hours in which to fix the mistake, even without reclassification privileges.
There is a new short value in the TMS_CONFIGURATION reference codelist called MTRECCLASSHOUR. The long value sets the number of hours after the initial classification during which users can change the classification.
During that time, the user has access to the Reclassify Verbatim Terms window, but the window displays only VTAs created by that user. The user will be able to change only those classifications that he or she created within the time limit set in the reference codelist.
This information is included in "Classify the Verbatim Term" and in "Reclassifying and Declassifying Verbatim Terms".
Until Release 4.5.1, you could not delete a TMS domain element in Oracle Clinical if any classifications or omissions existed for that domain/dictionary combination in any study. Now you can delete a project or study's domain element if no classifications or omissions exist for that particular project or study.
This information is included in "Linking an Oracle Clinical Study to TMS".
Release 4.5.1 includes a new model for symmetric replication. In the original multi-master approach, multiple instances replicated information to each other. In the new approach, which uses materialized views, slave instances send new data to a single master instance first, and then data on the master is replicated to all sites. The new approach prevents the No Data Found errors that sometimes occurred in the old model.
This change requires extra steps during the installation of Release 4.5.1, but thereafter the difference in approach is transparent to the user.
The new symmetric replication model was introduced in Release 4.0.6.12 and was patched in 4.0.6.14. Therefore the installation process is different if you are upgrading from either of those versions of TMS than if you are upgrading from any other version (Release 4.5 did not include the new symmetric replication model). The installation steps for each type of upgrade are included in the release notes for Release 4.5.1.
|
 Copyright © 1999, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
