| Oracle® Thesaurus Management System User's Guide Release 5.1 E53658-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Thesaurus Management System User's Guide Release 5.1 E53658-02 |
|
|
PDF · Mobi · ePub |
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 5.1 includes the following new features.
In WHO-Drug Format C, many drug names occur more than once in the coding level. They are distinguished from one another by auxiliary information such as the country where they are distributed, pharmaceutical form, and strength. Verbatim terms need to be classified to the dictionary term whose auxiliary information matches their own. To support this, TMS 5.1 includes the following enhancements:
You can allow nonunique terms in the coding and VT dictionary levels.
You can define sublevels of the classification level for each type of auxiliary information.
If you are using Oracle Clinical, you can set up question sets with additional input questions to collect auxiliary information for each source term.
A new type of classification called a verbatim term individual (VTI) is created when you classify a source term to a nonunique dictionary term. TMS handles VTIs similarly to VTAs, but with some differences. VTIs are always created as approved and are always specific to a domain—never global. Both VTAs and VTIs can be designated either misspelled or accepted. Both VTAs and VTIs are supported in the same dictionary.
If a dictionary is defined to allow autoclassification with auxiliary information, autoclassification classifies all occurrences of the same verbatim term with the same auxiliary information to the same dictionary term.
MedDRA supports classifying identical source terms to different dictionary terms without auxiliary information. For example, the source term "Migraine Headache" might sometimes be classified as "Headache" and other times as "Migraine."
TMS supports this by letting you allow nonunique terms in the VT level.
Autoclassification cannot handle coding source terms to different dictionary terms without auxiliary information.
Different instances of the same dictionary coding-level term may be classified to different high level terms—for example, Anatomical - Therapeutic - Chemical (ATC) terms in WHO-Drug Format C—based on the indication for which the drug was taken by a patient. In this case, multiple high-level terms are related to a single lower-level dictionary term with no primary path defined. TMS cannot derive the high-level term and creates an indication omission. After a user manually classifies the indication omission, TMS derives all current and future occurrences of the same term for the same verbatim term/indication combination.
To collect indication information for source terms:
If you are using Oracle Clinical you can create a question set variable of type Indication to collect the indication.
If you are using a different external source data system you must import "Indication" and the indication value as a value pair.
Note:
Indication omissions are created only after a verbatim term is classified. Users cannot classify an indication omission without an indication, and after a verbatim term is classified, there is no way to send an action message to the source system requesting information. So you must set up indication collection before classifying verbatim terms.Indication omissions are not replicated. If TMS runs in a distributed environment, indication assignments may vary across instances. Users can run the Indication Assignments Report on each instance and compare the results.
Existing reports that include VTAs now include VTIs too, when applicable:
Dictionary Impacts
Predict VTA/VTI
VTA/VTI Creation
Classification Statistics
VT Domain Differences
Classification to a New Domain
VT Modifications
The following are new reports:
VT Auxiliary Classifications
Unclassifiable Indication Omissions
Indication Assignments
A new dictionary term filter supports searching for dictionary terms using specific auxiliary information values.
Repository Maintenance APIs include VTI functionality.
The Maintain Repository Data window includes VTIs.
The Repository Authoring window includes VTIs.
The Copy Domain operation includes auxiliary information and uses mapping information provided by the user.
The Autoprocess VTAs job includes VTIs.
The Maintain Predictionary window includes VTIs.
Release 5.0 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 5.0, facilitating integration between the two systems.
In addition, because of the technology stack upgrade, the HTML Browser user interface has been rewritten using the Oracle Application Developer Framework. The functionality remains the same.
Release 5.0 supports integration with Oracle Health Sciences Data Management Workbench (Oracle DMW), a data transformation and discrepancy management system that can be integrated with Oracle Health Sciences InForm. Documentation is included in the Oracle DMW Installation Guide and User's Guide.
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 more 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.
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 more 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; 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 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. 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.
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".
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 "Look for a Good Match" 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, local 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, 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
