| 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 |
Oracle Thesaurus Management System (TMS) enables you to define elements other than dictionaries and domains in the user interface (see Chapter 6, "Defining and Loading Dictionaries" for instructions about defining dictionaries and domains). To define any of the following objects, you must have the tms_define_priv role.
If you have a distributed environment, you can perform the following tasks at the master instance only:
See Chapter 3, "Administration" for information on the following tasks that appear in the Definition navigation path:
Synchronizing Reference Codelist Settings (local instances only)
See Chapter 5, "Integrating TMS with Other Systems" for information on the following tasks that appear in the Definition navigation path:
HTML Layouts enable you to customize which data columns you present for Terminology Searches in the HTML Browser. Layouts are dictionary-specific, and rely on user-defined functions that derive TMS data from the production tables.
There is no security placed on HTML Layouts. You can edit or delete any HTML Layouts in the database.
This section includes the following subsections for creating HTML Layouts:
To delete a layout in this database, see "Deleting a Layout".
Before you can define an HTML Layout in the TMS application, you must define a function that you will use to derive data for that layout.
This section describes how to structure data in a package specification and package body so that the function can be used by an HTML Layout. For full samples, see the TMS Knowledge page on the My Oracle Support Web site.
The package specification must include each function you want to use in an HTML Layout. This example for the package dmo_package includes just two functions, LayoutOne and LayoutTwo. You can define as many packages as you want, each containing as many functions as you want.
Example 7-1 Sample Package Specification for HTML Layouts
CREATE OR REPLACE PACKAGE dmo_package IS
FUNCTION LayoutOne(
pRec IN sys_refcursor
)
RETURN Tms_qry_result_TypeSet PIPELINED
;
FUNCTION LayoutTwo(
pRec IN sys_refcursor
)
RETURN Tms_qry_result_TypeSet PIPELINED
;
END dmo_package;
/
sho err
grant execute on dmo_package to rxclin_read;
exec opa_ddl.CreateDropPublicSynonym( 'dmo_package');
HTML Layout functions handle data using reference cursors of the type Tms_qry_result_Type. You can use the columns in this cursor to specify which data are presented in HTML Layouts that use this function, and how this data should be presented. The column types are:
text_n columns: The fifteen text columns (text_1, text_2, …) describe which data columns you return to the layout. You can point directly to a specific data element such as the term name, or use TMS' data model to derive a related term record, like the term's parent.
description_n columns: The fifteen description columns (description_1, description_2, …), in a one-to-one relationship with the corresponding text_n columns, specify how each data element should be presented in the layout.
An HTML Layout uses one TMS dictionary and one layout function. This unique linkage is necessary because layout functions are written to be very dictionary-specific. In this section, you specify the dictionary that will use this layout, and the layout function that will deliver data to the HTML Layout.
To define a layout name and its function:
From the Definition menu, select Define HTML Layouts. The Define HTML Layouts window opens.
Choose Dictionary as the Ref Type. This is currently the only choice available.
From the Ref Name field, choose the dictionary to which you want to link this layout. You will only be able to use this layout in the HTML Browser when this dictionary is selected.
Enter a Display Name for this layout. This name appears in the Layout list in the HTML Browser when the linked dictionary is selected.
Enter the name of the function you want to use for this layout, in package_name.function_name format. If you want to use LayoutOne from Example 7-1, enter dmo_package.LayoutOne.
Save.
Proceed to "Defining the Layout Columns" to complete the layout definition.
Defining the columns for a layout means specifying which columns will display in the layout, in which order, and the headings that will display for those columns. You can choose the columns that are made available in the layout function: if you want a particular layout column to display the term name, and the layout function handles this data in the term_6 column, enter "6" as the Col ID for this column. See "Defining HTML Layout Functions" for information on writing an HTML Layout function.
You should define the columns in the order that you want them to display in the layout. The first column you enter in the Columns block will be the leftmost column in the layout.
The names that you enter for the columns are the names that display as headings when you use the layout in the HTML Browser. You can change column display names at any time.
To define the columns for a layout, choose the layout you want to modify from the upper block of the window, then repeat the following steps for each column in the layout.
In the Columns block, click in an empty row or add a record.
In the Col ID field, enter the number that corresponds to the data column you want to use in the layout function. If you want this column to display the term name, and the layout function handles this data in the term_6 column, enter "6" for this column.
Enter the Display Name for this column. The HTML Browser displays this name in the column heading when it displays results in this layout.
Repeat for each additional column, then save. TMS makes this layout available to the HTML Browser.
You can remove HTML Layouts from the database by first deleting all of the layout's columns, then deleting the layout itself.
This section contains the following topics:
You can customize the layout of TMS reports using Oracle XML Publisher. You can download the default template and, for example, change the background color, add conditional statements, insert logos and other images, change the order of the fields displayed. You then upload this customized template back into TMS with its own name. Each time a user runs the report, he or she can choose to use the default template or a customized template.
TMS allows you to upload multiple templates for each report.
You cannot overwrite or delete the default Oracle template.
The TMS_DEFINE_PRIV privilege is required to customize templates.
To download a report template, follow the instructions below:
Log into TMS.
Click the HTML Browser link from the TMS opening screen. The HTML Browser opens.
Click the Reports tab.
Select the appropriate report from the Report field. The form refreshes and lists the selected report's templates in the table below.
From the list, click the appropriate template name. (The predefined default template is called the Oracle Template.) A standard File Download pop-up box opens.
Click Save. A standard Browse pop-up box opens.
Navigate to the location where you want to work on the template and click Save. The system saves a copy of the template as an .rtf file on your local system.
Save the file.
To create your first custom template for any report, begin by downloading the default Oracle template. You can create additional custom templates or modify existing custom templates at any time.
Open the downloaded template file locally in MS Word.
Make the changes you require. For information about using XML Publisher, go to the following Web site:
http://www.oracle.com/technology/products/xml-publisher/index.html
Save your changes.
To upload the template after customization, follow the steps below:
Log into TMS.
Click the HTML Browser link from the TMS opening screen. The HTML Browser opens.
Click the Reports tab.
Enter a name for the new customized template in the Template Name field.
Using the Browse… button, select the .rtf template file from your system.
Click the Create New Template button. The form refreshes and adds the customized template to the list of templates for this report.
To update or delete an existing template, follow the steps below:
Log into TMS.
Click the HTML Browser link from the TMS opening screen. The HTML Browser opens.
Click the Reports tab.
Select the appropriate report from the Report field. The form refreshes and lists the selected report's templates in the table below.
Choose the appropriate template by clicking its corresponding button in the Select column. You may select only one template at a time.
Click Checkout Template. Your user ID appears in the Checkout column.
Only one person can check out a template at a time. The template version that was current at the time of checkout remains available for use in TMS until the updated version is uploaded. The new version is then available.
Note:
If you decide not to update or delete the template, click Undo Checkout.If you are updating the template, download the template and modify it locally; see "Downloading a Report Template" and "Modifying a Report Template".
Select the report you are updating or deleting, if it is not already selected.
If you are updating the report, enter a template name and browse for the modified local .rtf template file, then click Upload Template. The system updates the template and automatically checks it in.
If you are deleting the template, click Delete Template.
TMS does not allow you to overwrite or delete the default Oracle template.
This section includes the following topics:
You can use actions for communication with personnel using an external source data system, or for communication within TMS, about an omission.
There are three types of actions: Answerable Actions and Unanswerable Actions, both of which TMS sends to an external system, and Internal Actions, which are used within TMS.
After you apply an Action of any type to a term, TMS automatically applies the same Action to new occurrences of the same term in the same dictionary/domain combination.
Note:
Before TMS Release 4.6, Answerable actions were known as Conditional actions, and UnAnswerable Actions were known as Never Expire actions. Internal Actions are new in TMS Release 4.6.Answerable Actions Sometimes a verbatim term cannot be classified either automatically or manually because the verbatim term itself is flawed. In this case, the person trying to manually classify the term instead associates an Action with the omission and sends it back to the external system requesting that the term be amended and resubmitted to TMS.
For example, TMS does not support combined verbatim terms. TMS can process only one symptom per term in a medical dictionary; either bad headache or nausea, but not bad headache and nausea. In this example, you could apply an Action with the text "Split the term" to the verbatim term bad headache and nausea. A verbatim term may also be ambiguous—too vague; for example, head—or completely garbled due to a typing error. In this case you could apply an Action with the text "Clarify the term" to the verbatim term.
Answerable actions allow a user in the external system to send a comment back to TMS. When that happens, TMS resumes ownership of the omission and a TMS user must take the next step: either classifying the term or sending a discrepancy message back to the external system to respond to the external comment. For example, you assign an Action to the term "Pain" with the text, "This term is too vague. Please be more specific." An external user responds, "The patient did not provide any further information." You see this response in the Classify VT Omissions window, All VT tab, Action Text field. You can use a discrepancy message to respond, for that source term only, "TMS cannot process this term without information about where in the body the pain occurred. Please get additional information."
See "Discrepancy Message" for further information about Discrepancy Messages.
Unanswerable Actions If you assign an Action of type Unanswerable to a term, TMS does not register comments sent back to TMS from the external system. If an external system user replies to the Action text for a particular source term without changing the term itself, TMS sends the same Action text back during the next data exchange job. For example, if you assign an Action definition with the text "This term is too vague. Please be more specific" to the term "Pain" and an external system user responds, "The patient did not provide any further information," this comment never appears in TMS, the omission ownership remains set to the external system, and TMS sends back the original Action text ("This term is too vague. Please be more specific") in the next data exchange with the external system.
Note:
The external system does not "see" and so does not display the Action type. Therefore the external system user does not know whether TMS can read his or her response or not.Use unAnswerable Actions in cases where you know a particular response is always wrong, or if you do not have the resources to support a dialog.
Internal Actions Internal Action definitions are used for two purposes, Action Approval and Internal Communication:
Action Approval. Use Internal Actions with a base Answerable Action as a mechanism for approving the assignment of a particular Answerable Action to a particular verbatim term. After a TMS user approves the Action assignment, TMS sends the Answerable Action to the external system.
To use Internal Actions as a mechanism for approving the assignment of a particular Answerable Action to a particular verbatim term, do the following:
Set up Action approval:
In the dictionary/domain combinations where you want to require the approval of Action assignments, check Action Appr Reqd?; see "Assigning a Dictionary to a Domain".
For each Answerable Action that you may use in a dictionary/domain combination where Action approval is required, define an Internal Action with the Answerable Action as the base Answerable Action. Use a naming convention so that coders can select the correct Internal Action to assign to an omission; see "Defining an Action". When you specify the base Answerable Action, TMS supplies its text as the text for the Internal Action. It makes sense to keep them the same.
Assign actions to terms. In the Classify VT Omissions window under Omission Management, if you are working in a dictionary/domain combination where Action approval is required, TMS displays only active internal and unAnswerable Actions in the Action drop-down list; see "Classifying Terms Manually".
In the Approve Action Assignments window under Omission Management, a user with the TMS_APPROVE_PRIV role can approve an Internal Action assignment. TMS then applies the Internal Action's base Answerable Action to the term and sends the term with its Action to the external source data system during the next data exchange (Batch Validation for Oracle Clinical).
If the user instead rejects the assignment, or assigns a different Action, TMS removes the Internal Action assignment. A record of the Internal Action assignment is available in the status history of the term.
Internal Communication. Use Internal Actions without a base Answerable Action as a mechanism to indicate to other coders that someone is already working on a particular verbatim term.
For example, a coder may need to check with his or her supervisor before classifying a verbatim term. To avoid a duplication of effort, the coder first applies an Internal Action with no base Answerable Action, and with text such as "Inquiry in progress" to the term. When the coder collects the required information, he or she can either classify the term or apply another Action to it.
Any user with the privileges normally required can either classify or apply another Action to the term. TMS then removes the Internal Action without a base Answerable Action from the term.
To use Internal Actions for internal communication only, do the following:
Define one or more Internal Actions without a base Answerable Action.
Assign actions to terms. In the Classify VT Omissions window under Omission Management, apply an Internal Action without a base Answerable Action to a term; see "Classifying Terms Manually".
When you are ready, classify the term or assign a different Action to it.
Using actions involves many parts of TMS described elsewhere in the documentation as follows:
Defining Actions is described in this section.
Requiring Approval for Action Assignments. You can require that actions assigned to omissions be approved before they are sent to the external system. You require this approval for a particular dictionary/domain combination; see "Assigning a Dictionary to a Domain". Internal Actions are used for this purpose; see "Internal Actions" for further information.
Applying Actions to Omissions. You assign actions to omissions in the Classify VT Omissions window; see "Apply an Action or Discrepancy Message to a Term" for details.
Applying Actions to VTs Before They Occur. You can apply actions to verbatim terms proactively, even before a verbatim term enters the system. In the Maintain Actions window, you can enter any verbatim term you choose (or any term that you think may be entered as a verbatim term in the future) and assign an Action to it. See "Maintaining Action Assignments".
Viewing Action Assignment History. You can see actions that have been assigned to a term as follows:
You can see the actions that have been assigned to a verbatim term in the Distinct VT Actions tab of the Classify VT Omissions window; see Chapter 10, "Omission Management."
You can see the actions that have been assigned to a specific source term in the All VT Actions tab in Classify VT Omissions form; see Chapter 10, "Omission Management."
The Status/Notes window, called from Classify VT Omissions, Approve VTAs, Approve VTA Assignments, or VT History window, shows all term status history information, including actions; see "Using the Status/Notes Pop-up Window".
The HTML Browser displays terms' complete Action history; see "Viewing a Term's Action History"
To create an Action Definition, do the following:
From the Definition menu, select Create Action Definitions. The Create Action Definitions window opens.
In the Action field, enter a short (no more than 15 characters), descriptive name for the Action. In the bad headache and nausea example above, this might be "Split term."
Note:
If you are defining an Internal Action with a base Answerable Action, use a naming convention such as base Answerable Action name _INT to name the Internal Action, so that coders can select the correct Internal Action to assign to an omission. For example, if the base Answerable Action is named SPLIT TERM, name the corresponding Internal Action SPLIT TERM_INT. (Note that if you follow this naming convention, which requires 4 characters for the Internal Action name, base Answerable Actions can have a maximum of 11 characters in their name.)In the Action Type field, select Answerable, Unanswerable or Internal. See "Action Types" for information.
When the choice is Internal for the purpose of requiring an Action assignment to be approved before sending to the external system, you must select an option from the Base Answerable Action LOV. This LOV contains all defined Answerable Actions. Each Internal Action can be based on only one Answerable Action. Likewise, an Answerable Action can be associated with only one Internal Action.
Leave the Status field value set to Active. If you need to stop using the Action in the future, you can set the status to Retired. The system then removes all current assignments of the Action.
Note:
If an Action has never been applied to a term, you can delete it. After it has been applied, you can only retire it.Base Answerable Action. Use this field only if you are defining an Internal Action with a base Answerable Action for use in one or more dictionary/domain combinations where Action approval is required. Specify the Answerable Action to be sent to the external system if the assignment of the Internal Action you are defining is approved.
An Internal Action can have only one base Answerable Action (and should have a similar name to the Base Answerable Action's name or text; see above). An Answerable Action can be associated with only one Internal Action as a base Answerable Action.
Note:
In dictionary/domain combinations where Action approval is not required, you can apply an Answerable Action directly to an omission, even if it is associated with an Internal Action.In the Text field, enter the default text to send to external system users, explaining what they need to change to allow the system to process the term. In the same example, this text might be "Please split this term."
If you are defining an Internal Action with a base Answerable Action, click in the Text field. TMS populates it with the base Answerable Action's text. This text will be sent to the external system associated with a source term after the Action assignment is approved. The person who approves the assignment can modify the text.
In the External System field, specify one or more external systems collecting source terms (Oracle Clinical, for example) to which you may want to send this Action.
In the Omission Status field, enter the omission status you want the external system to assign to the omission when it returns from TMS. In Oracle Clinical, this status is normally Inv Review (Investigator Review) to indicate that the investigator must take the next step in resolving the discrepancy, but you can enter any valid status.
An external system-specific LOV is available for this field; you can define this LOV in the Multiple Term Action Omission Statuses LOV field of the Define External Systems window.
For each external system, select one omission status.
Save.
Search objects contain algorithms used to search the TMS repository in three situations:
To find matches for verbatim terms during Autoclassification.
To find Candidate Terms during manual classification.
To find repository terms in the Extended Search window, which can be opened from the Browse Repository Data window and the Classify VT Omissions window.
In the Define Search Objects window you activate each search object in the dictionaries and domains you want, and specify how you want to use the search object (see "Defining a Search Object").
TMS runs the Nonapproved VTA search before other search objects during Autoclassification, manual classification and extended searches. It searches in the current domain for an exact match that is a Nonapproved VTA. You cannot see the Nonapproved VTA search object in the Define Search Objects window because you cannot modify it. However, you see references to it in the Search Type and Origin fields in several windows.
Sample Domain Match Search Object TMS includes a pre-defined search object called Domain Match that is available for you to use as you wish. It searches for an exact match of a VTA in another domain. If it finds more than one match, it returns multiple Candidate Terms. If it finds one and only one match, it either autoclassifies the term or returns a Candidate Term, depending on the Approval Type setting. In addition, if it finds one and only one match:
If the verbatim term's dictionary/domain combination allows classification to nonapproved dictionary terms, the Domain Match search object includes VTAs linked to nonapproved dictionary terms in its search.
If the verbatim term's dictionary/domain combination does not allow classification to nonapproved dictionary terms, the Domain Match search object does not include VTAs linked to nonapproved dictionary terms in its search, even if they exist in other domains.
In addition, you can write your own search algorithms in the database and use the Define Search Objects window to identify them to TMS and define their usage.
This section discusses defining a search object using the graphical user interface. For information about defining a search object using the API, see the Oracle Thesaurus Management System Technical Reference Manual.
To use either the pre-packaged search object Domain Match or a user-defined search object, you must activate it and specify how you want to use it for each dictionary. You can use different settings in different domains if you want to.
To define a search object:
From the Definition menu, select Define Search Objects. The window opens with the Define Search Objects tab selected.
Specify the following information about your search object, then save:
Name The name of the search object.
Inherit? If selected, the search object you create and assign to this base dictionary will also be created for all virtual dictionaries that use the base dictionary.
Description Enter an explanation of what the search object searches for. Up to 2000 alphanumeric characters.
Use VTA? Applies to Autoclassification (Autocode Search Objects) only. Select if you want the system to search for VTAs as well as dictionary terms during Autoclassification.
Stop 1:m? Exit criteria. This applies only to Autoclassification (Autocode Search Objects). Select if you want the system to stop the search if it finds more than one match using any one search algorithm. (If the system finds more than one match during a Candidate Term search or an extended search, it will return all the matches it finds.)
Approval Type Select one of the following to specify the behavior you want if the search finds one and only one match:
Approved. TMS automatically creates the VTA and uses it to derive information.
Omission. TMS does not create a VTA, but displays the omission with the match it finds as the one and only Candidate Term, with the name of the search object that found it, in the Classify VT Omissions window. No values can be derived for the verbatim term until you classify it. When you classify the omission, you can choose to create either an approved or a Nonapproved VTA.
Autocode Object Enter the name of the function you have written for TMS to run during Autoclassification. For the Domain Match search object this is predefined. For user-defined search objects, enter the function name here or, if the function is included in a package, enter package_name.function_name. See "Creating Custom Search Algorithms".
Candidate Object Enter the name of the function you have written for TMS to run to generate Candidate Terms during manual classification. For the Domain Match search object this is predefined. For user-defined search objects, enter the function name here or, if the function is included in a package, enter package_name.function_name. See "Creating Custom Search Algorithms".
Candidate Type Select Package. TMS does not currently support the Form option.
Extended Search Object Enter the name of the function you have written for TMS to run to browse the repository during an extended search. For the Domain Match search object this is predefined. For user-defined search objects, enter the function name here or, if the function is included in a package, enter package_name.function_name. See "Creating Custom Search Algorithms".
This section includes the following topics:
You must specify the dictionaries with which each Search Object is available for use, as follows:
Click the Dictionary Mappings to Search Objects tab.
From the Dictionary list, choose the dictionary to which you want to apply the search object.
For each search object you want to use against this dictionary, fill in the fields in the following order, then save:
Search Object Select the search object from the scrolling list.
Order Specify the order in which you want TMS to execute this search algorithm in relation to the others listed here. Numbers do not have to be consecutive. Search objects with lower numbers will be executed before those with higher numbers.
Domain The list includes all TMS domains with which the dictionary is linked. The domain-specific settings in this lower portion of the window override the corresponding dictionary-wide settings in the upper portion of the window. If you want to use the search objects the same way in all domains, do not enter a domain name here.
Disabled? Select if you want to disable the search object in this domain/dictionary combination.
Note:
If you have used a search object in a dictionary/domain combination and then disabled it, the disabling applies only to future occurrences of terms. Users can still query for and find omissions created using the search object in the Classify VT Omissions window.Approval Type From the list, choose the result you want TMS to return if it finds one and only one match during the search in this domain/dictionary combination. See "Approval Type".
If you decide that you no longer want to use a particular search object with a dictionary in any domain, you can remove the search object by using the Dictionary Mappings to Search Objects tab.
Omissions previously created using the search object still exist and are queryable and viewable in the Classify VT Omissions window. However, the Search Object field for these omissions is blank, and the system does not use the search object to create any additional omissions associated with the dictionary.
To remove a search object's association with a dictionary:
From the Definition menu, choose Define Search Objects.
Query for the search object you want to remove from a dictionary.
Click the Dictionary Mappings to Search Objects tab.
From the Dictionary list, choose the dictionary from which you want to remove a search object. TMS lists the search objects defined for this dictionary.
Scroll to, or query for, the search object you want to remove, and select its row.
With the search object's row highlighted, click in one of the three detail fields (Domain, Disabled?, and Approval Type), and delete the record. This deletes the detail records for this association, which you must do before deleting the association itself.
Select the search object again, and delete the record. TMS deletes the search object's association with this dictionary.
Save. TMS deletes the search object's association with this dictionary.
If you decide that you no longer want to use a search object with any dictionary, you can delete it entirely from TMS. Previously created omissions still exist and are queryable and viewable in the Classify VT Omissions window. However, the Search Object field for these omissions is blank, and the system does not use the search object to create any additional omissions.
To delete a search object:
From the Definition menu, choose Define Search Objects.
Query for the search object you want to remove from a dictionary and select it.
From the Record menu, choose Delete Record.
Save. TMS deletes the search object.
Each of the search algorithms provided with TMS searches only for direct matches to the verbatim term in the TMS repository. You may want to take advantage of the text-retrieval capabilities available in the Oracle database. The interMedia Text software, formerly known as the Context Server Cartridge, is integrated in the RDBMS. See "Entering a Context Query".
To create a custom search algorithm, create a PL/SQL function in the database and enter its name in the Search Object Definition window in TMS in the appropriate field—Autocode Object, Candidate Object, or Extended Search Object—and set the candidate_type='package'. For an overview, see "Defining a Search Object").
If the function is part of a package, follow the naming convention package_name.function_name for functions. When TMS runs Autoclassification, a Candidate Term search, or an extended search, it calls the function in the order you specify in the Exec Order field.
You will probably want to make each search algorithm available in all three situations, but this is optional.
The input and output parameters vary in each situation as follows:
You can create one or more custom search algorithm to supplement TMS's Autoclassification process. Create a PL/SQL function in the database and enter its name in the Search Object Definition window in TMS in the Autocode Object field (see "Defining a Search Object"). Each Autoclassification search algorithm must have the following specifications:
FUNCTION function_name ( |
|||
pDefDictionaryId |
IN |
tms_def_dictionaries.def_dictionary_id%TYPE |
|
, pDefDomainId |
IN |
tms_def_domains.def_domain_id%TYPE |
|
, pVtLevelId |
IN |
tms_def_levels.def_level_id%TYPE |
|
, pVtCodeLevelId |
IN |
tms_def_levels.def_level_id%TYPE |
|
, pVTASearchFlag |
IN |
VARCHAR2 |
|
, pTermUpper |
IN |
tms_dict_contents.term_upper%TYPE |
|
, pVDefDictionaryID |
IN |
tms_def_dictionaries.def_dictionary_id%TYPE |
|
, pCutoffDate |
IN |
tms_def_dictionaries.cutoff_date%TYPE |
|
, pDictContentid |
IN |
OUT |
tms_dict_contents.dict_content_id%TYPE |
) RETURN PLS_INTEGER; |
|||
The function_name may be part of package_name.function_name and must correspond to the value entered in the Autocode Object field of the Define Search Objects window.
The function has one output parameter that identifies the dictionary term or VTA match it finds. The function returns an integer as follows:
| Value | Returned if Function Finds | Next, TMS |
|---|---|---|
| 0 | no matches | runs next search object, if any |
| 1 | one and only one match | stops Autoclassification, returns match |
| 2 | more than one match | if the exit criterion Stop 1:m is set to Y, Autoclassification stops and returns the search object that found the matches; if the exit criterion is set to N, TMS runs the next search object, if any. |
You can create one or more custom search algorithm to supplement TMS's Candidate Term search process. Create a PL/SQL function in the database and enter its name in the Search Object Definition window in TMS in the Candidate Object field (see "Defining a Search Object"). Each candidate search algorithm must have the following specifications:
FUNCTION function_name ( |
||
pDefSearchId |
IN |
tms_vt_omissions.def_search_id%TYPE |
, pDefDictionaryId |
IN |
tms_vt_omissions.def_dictionary_id%TYPE |
, DefDomainId |
IN |
tms_vt_omissions.def_domain_id%TYPE |
, pVtLevelId |
IN |
tms_def_levels.def_level_id%TYPE |
, pVtCodeLevelId |
IN |
tms_def_levels.def_level_id%TYPE |
, pTermUpper |
IN |
tms_dict_contents.term_upper%TYPE |
, pVDefDictionaryID |
IN |
tms_def_dictionaries.def_dictionary_id%TYPE |
, pCutoffDate |
IN |
tms_def_dictionaries.cutoff_date%TYPE |
) RETURN VARCHAR2; |
||
The function_name may be part of package_name.function_name and must correspond to the value entered in the Candidate Object field of the Define Search Objects window.
The function returns a string of characters that populates the Where clause, which populates the lower block of the Classify VT Omissions window. The function is invoked by the user during manual classification (see "Candidate Terms").
In addition, you can restrict an algorithm's search to only current terms by adding the following to the populated where clause:
AND end_ts = to_date(3000000, 'J')
You can create one or more custom search algorithm to supplement TMS's extended search process, which can be invoked from the Browse Repository window or the Classify VT Omissions window. Create a PL/SQL function in the database and enter its name in the Search Object Definition window in TMS in the Extended Search Object field (see "Defining a Search Object"). Each extended search algorithm must have the following specifications:
FUNCTION function_name ( |
||
pDefSearchId |
IN |
tms_vt_omissions.def_search_id%TYPE |
, pDefDictionaryId |
IN |
tms_vt_omissions.def_dictionary_id%TYPE |
, DefDomainId |
IN |
tms_vt_omissions.def_domain_id%TYPE |
, pVtLevelId |
IN |
tms_def_levels.def_level_id%TYPE |
, pVtCodeLevelId |
IN |
tms_def_levels.def_level_id%TYPE |
, pTermUpper |
IN |
tms_dict_contents.term_upper%TYPE |
, pVDefDictionaryID |
IN |
tms_def_dictionaries.def_dictionary_id%TYPE |
, pCutoffDate |
IN |
tms_def_dictionaries.cutoff_date%TYPE |
) RETURN VARCHAR2; |
||
The function_name may be part of package_name.function_name and must correspond to the value entered in the Extended Search Object field in the Define Search Objects window.
The function returns a string of characters that populates the Where clause, which populates the Extended Search window.
This section contains the following topics:
Standard-type named relations create a structure for weak dictionary folders by describing the nature of relations between terms. You can define named relations as being one-directional or bi-directional, as shown in Figure 7-1.
Figure 7-1 One-directional and Bi-directional Relationships
Bi-directional relationships like the one above between "United States" and "California" have two components, an Indicator relationship and a Reciprocal Indicator relationship. Indicator relationships describe the link from the source term to the reference term, and Reciprocal Indicators describe the reverse relation. If "United States" is the source term for the above relation, "Broader Term Than" is the Indicator for this relationship and "Narrower Term Than" is the Reciprocal Indicator.
One-directional named relations have Indicator relationships only. Thus, in the example one-directional relation above, no relationship is defined from "state" to "California."
Named relations also define the cardinality of the relation between terms. The cardinality of a relationship determines the maximum number of reference terms (one or many) to which a term may be linked. If you specify Many Cardinality for the Indicator relationship but Single Cardinality for the Reciprocal Indicator, then source terms can be linked to many reference terms, and each reference term must link to only one source term.
Because named relations create a dynamic dictionary structure, you cannot enforce that named relations be mandatory. You can, however, enforce mandatory relations between levels in a strong dictionary; see "Mandatory Relations".
TMS does not allow circular named relations of the same type among terms. That is, if you define an Indicator relationship of a particular type (such as Related Term) between Term A and Term B, and another Indicator relationship of the same type between Term B and Term C, you cannot define an Indicator relationship of the same type between Term C and Term A. Activation of the final relationship in the circle fails. (The reason for this restriction is that the ANSI/NISO Z39.19-1993 standards for thesauri specify that you must be able to represent a thesaurus structure using a flat display, which is impossible with circular relations.)
You can introduce a named relationship into your installation using the Define Named Relationships window, or by loading the relationship directly into the repository with a load script (see "About Load Scripts"). TMS stores named relations in the tms_def_named_rels table, and enables you to use any named relation to link terms in any dictionaries throughout the TMS installation.
See "Defining Named Relations" and "Creating Named Relations Between Terms" for further information, including information on other types of named relations.
You can use named relations to create browsable relations between dictionary terms.
There are three types of named relations:
Standard. Use standard named relations to create relations among terms in weak dictionary folders or to supplement existing relations among terms in strong dictionaries.
After you define a standard named relation, you can create standard named relations between terms in the Repository Authoring window under the Repository Maintenance menu.
Translation. Use named relations of type Translation to define a relationship between a term in one dictionary and a term with the same meaning in another dictionary in a different language. TMS allows named relations of type Translation only between terms in different dictionaries, each of which must have a different language defined.
After you define a Translation named relation, you can create Translation named relations between terms in the Repository Authoring window under the Repository Maintenance menu.
Release Label. Use named relations of type Release Label to create relations between terms in the same or different dictionaries at different points in time.
This is especially useful for maintaining an audit trail of complex changes to a term from one dictionary version to another; for example, where two terms are merged, or one term is split into two or more terms, or one term is substituted for another.
After you define a Release Label named relation, you can create Release Label named relations between terms in the Release Label Authoring window under the Repository Maintenance menu; see "Using the Release Label Authoring Window".
Release Label Named Relation Example 1 The MedDRA 7 high level terms "Liver and spleen infections" and "Gallbladder infections" were merged in MedDRA 8 into a single term, "Hepatobiliary and spleen infections."
If you are currently using MedDRA 7 in TMS, do the following:
After upgrading to TMS 4.6, define a label prefix for MedDRA 7: 7.0.
Create a virtual dictionary of MedDRA 7. TMS creates a Release Label for the virtual dictionary.
Define a named relation called "is merged into;" see "Defining Named Relations".
Update the label prefix to 8.0.
Load data for MedDRA 8 into the predictionary tables.
Define two named relations in the Release Label Authoring window, one from "Liver and spleen infections" to "Hepatobiliary and spleen infections" and one from "Gallbladder infections" to "Hepatobiliary and spleen infections." In both cases, given the definition "is merged into," "Hepatobiliary and spleen infections" must appear in the Reference section of the screen. See "Creating Named Relations Between Terms". Use the NEXT setting for "Hepatobiliary and spleen infections," which is in the predictionary tables and does not yet have a Release Label.
Activate the data (MedDRA 8).
View the data in the HTML Browser; see "Examining a Term's Details and History".
Release Label Named Relation Example 2 If you have already loaded and activated MedDRA 8, do the following to trace the relationship between MedDRA 7 high level terms "Liver and spleen infections" and "Gallbladder infections" the single MedDRA 8 high level term, "Hepatobiliary and spleen infections":
Create label prefixes for MedDRA 7 and MedDRA 8.
Create virtual dictionaries for MedDRA 7 and MedDRA 8. TMS creates a Release Label for each.
Define the "is merged into" named relation as above.
Define named relations between the two terms in MedDRA 7 and the term they are merged into in MedDRA 8.
View the data in the HTML Browser; see "Examining a Term's Details and History".
To create a new named relation:
From the Definition menu, select Define Named Relations. The Define Named Relations window opens, with the Named Relation tab displayed.
Note:
By clicking the Multi Display Named Relations tab, you can view all of the named relations defined in this TMS installation. Examine the existing named relations before creating a new named relation to avoid creating similar but extraneous relationships.Define the Indicator relationship:
Define the Reciprocal Indicator:
In the Name field, enter the relationship name that will appear for relations from the reference term back to the source term. If the relationship does not have a reciprocal, leave the Name field blank.
Select the Many Cardinality box if you want to allow multiple reference terms to relate to one (or more) source terms using the Reciprocal Indicator relationship.
Define the relationship details. All the fields in the Details block are optional except for the Type field.
In the Relationship Code field, you can enter an optional code about this named relation. For example, when loading named relations into TMS via the API, you could populate the Relationship Code with the vendor-supplied dictionary from which you loaded the relationship, or the relationship's ID in that dictionary.
Select a Type.
Standard. Use for normal named relations between terms. TMS does not enforce any special behavior.
Translation. TMS validates that the two terms in the relation are from dictionaries that have different languages specified. Because translation relationships must be between dictionaries of different languages, you can only instantiate such relations as cross-dictionary relations. See "Creating Cross-Dictionary Relations Between Terms" for instructions on using these relationships in the Repository Authoring window.
Release Label. Release Label named relations create links between terms in the same or different dictionaries at different points in time; see "Types of Named Relations".
In the Short Name field, enter a unique value for the short name of this relationship. TMS allows names containing up to ten bytes of alphanumeric text. If you leave this field blank and save the record, TMS supplies a default, unique value.
In the Activation Rule field, you can specify a function that you want to use as the Activation Rule for this relationship. "Writing Named Relation Activation Rules".
In the Category field, you can enter a category to define further this named relation.
In the Description field, you can provide more information about this named relation. Information entered here could help other TMS users.
Save. TMS records the named relation in the repository, and updates the audit fields in the bottom of the window.
You can modify many attributes of named relations in the same manner. Because TMS only uses the internal ID of the relationship to identify which named relation is associated with a particular relation, you can change any information about an existing named relation except its ID, cardinality, and type.
For each named relation you define, you must specify the dictionaries and dictionary combinations where it should be available for creating named relations between terms.
To specify the dictionaries where a named relation is available for use, do the following:
In the Define Named Relations window, with the named relation for which you want to specify dictionaries selected, click Dictionary NRLs. The Define Dictionary Named Relationships window opens.
Click in the first empty row. The fields become enterable.
In the From Dictionary column, from the list, select a dictionary in which you want the named relation to be available.
In the To Dictionary column, from the list, select a dictionary:
To make the named relation available to define relations between terms in a single dictionary, choose the same dictionary you specified in the From Dictionary column.
To make the named relation available to define relations between terms in the dictionary you specified in the From Dictionary column and a second dictionary, choose the name of the second dictionary.
Note:
In the To Dictionary list of values, TMS displays:The From Dictionary; you can always define relations between terms in the same dictionary.
Dictionaries that have a filter dictionary link with the From Dictionary; one is a filter of the other.
Dictionaries with a cross-dictionary link defined to the From Dictionary. To define a dictionary link, go to the Define Dictionaries window, select a dictionary, and click the Dictionary Link tab. See "Defining Links Between Dictionaries".
Leave Status set to Active.
You can set the status to Retired in the future to prevent this named relation definition's being used to create additional relations in this dictionary or dictionary combination. This is the only modification possible.
You can set the status back to Active only if the To and From Dictionaries have one of the relationships described in the above Note.
Save.
Named relation Activation Rules can perform further validation of the terms and their relationship(s) before Activation. For example, if you create a named relation "Abbreviation for," you could write a function to verify that the reference term you plan to use as the abbreviation is, in fact, shorter in length than the original term.
Named relation Activation Rules must be part of database packages, and the proper format for definition is package_name.function_name.
The function must use the parameters described in Table 7-1.
Table 7-1 Parameters Required for Named Relation Activation Rules
| Parameter (In/Out) | Datatype (Size) | Description |
|---|---|---|
|
pRelId (in) |
NUMBER(10) |
ID number of the relation. |
|
pGroupId (in) |
NUMBER(10) |
ID number of the Activation Group. |
|
pNRLId (in) |
NUMBER(10) |
ID number of the named relation you are using for this relation. |
|
pConId (in) |
NUMBER(10) |
ID number of the first term in the relation. |
|
pConRefId (in) |
NUMBER(10) |
ID number of the reference term in the relation. |
|
pDomId (in) |
NUMBER(10) |
ID number of the domain in which you are creating this relation. |
|
pCreatedBy (in) |
VARCHAR2(30) |
The user name of the TMS user who created this relation. |
|
pLevelId (in) |
NUMBER(10) |
ID number of the level in which the first term resides. |
|
pLevelRefId (in) |
NUMBER(10) |
ID number of the level in which the reference term resides. |
|
pDML (in) |
VARCHAR2(15) |
The requested Action you want to perform on the TMS preproduction repository. Values are 'I' (Insert), 'U' (Update), and 'D' (Delete). |
|
pDefDictId (in) |
NUMBER(10) |
ID number of the dictionary in which the first term resides. |
|
pDefDictRefId (in) |
NUMBER(10) |
ID number of the dictionary in which the reference term resides. |
|
pRelType (in) |
VARCHAR2(15) |
The type of relation you are loading: DT – Dictionary Term DPL – Domain Primary Link PPL – Primary Path Link VTA – Verbatim Term Assignment |
|
pRelSubtype (in) |
VARCHAR2(15) |
If the RelType is VTA, the subtype can either be AC (Accepted) or MS (Misspelled). For any other relation type, possible subtype values are E (External), C (Company), and D (Domain). |
|
pActivationId (in) |
NUMBER(10) |
Internal ID used to track the Activation process. |
|
pTransId (in) |
NUMBER(10) |
Not used in this release. |
|
pStatus (in) |
VARCHAR2(15) |
An optional description of the status of this term. |
|
pCommentText (in) |
VARCHAR2(200) |
Comment about this Activation Rule. |
|
pErrorMsg (in/out) |
VARCHAR2(200) |
Error message associated with this record. This is the only part of a production record that you can change with this function. |
This section describes the following topics relating to Informative Notes and Informative Note Attributes:
Informative notes are data structures that you can create to provide more information about a term, relation, VTA or dictionary in the database. The advantage that Informative Notes offer over the other detail items—the code, alternate code, category, and the value_1 through value_4 columns—is their flexibility. Using Informative Notes, you can define a URL, a Character Large Object (CLOB), or a note of predefined length containing character, number, mixed, or date data.
Each time you create an Informative Note, you must base it upon an Informative Note Attribute, which gives the note its data type, maximum length, and other properties. Using attributes as the basis for Informative Notes saves time during note definition and provides more consistency among the Informative Notes defined in your database.
Because Informative Notes require attributes, start by defining the Informative Note Attributes that you want to make available in your database. Each attribute in the database has an attribute type and data type, both of which control the types of data that you can save in notes that are based on that attribute definition. You can also delete attributes using this window, as long as the attribute has never been used as the basis for an Informative Note. If any TMS user has created an Informative Note using that attribute, you cannot delete it from TMS.
To summarize the process of creating Informative Notes:
Define an Informative Note Attribute. This step creates the definitions that TMS users choose from to define Informative Notes for specific records.
The instructions for defining Attributes are in this section.
Define an Informative Note. You can create Informative Notes to enhance one or more TMS data records. You must base it upon an Informative Note Attribute definition.
You can create a note to supplement any of the following types of records:
Dictionaries: see "Defining Dictionary-wide Informative Notes"
Terms or Relations: see "Creating Informative Notes for Terms and Relations"
VTAs and Action Assignments: see "Using the Status/Notes Pop-up Window"
In addition, you can create Algorithm Informative Notes for filter dictionaries such as MedDRA SMQs; see "Defining Informative Notes for SMQ Algorithms".
For each attribute you define the following specifications for Informative Notes based on that attribute:
The attribute label is a name for the category of data stored in Informative Notes based on this attribute.
There are several types of Informative Note Attributes:
Standard. For Informative Notes that contain text, or a number or date, to provide supplementary information about a term, relation, VTA, or dictionary.
URL. For Informative Notes that are character strings representing URLs.
Workflow. For Informative Notes used in workflow processes, such as approval of VTAs. If you are creating an Informative Note during classification, VTA approval, or reclassification, TMS requires that you base the note on an attribute of type Workflow.
Algorithm. For use with filter dictionaries such as MedDRA SMQs. See "Defining Informative Notes for SMQ Algorithms" for further information.
You can define attributes to store character information, dates, numbers, or CLOBs. TMS uses the Memo data type to store CLOB data.
The length dictates the maximum number of bytes that you can store in Informative Notes based on this attribute.
This section includes the following topics:
This section describes how to add a new Informative Note Attribute to the database, using the Define Informative Note Attributes window. Launch this window by navigating to Definition, then Define Informative Note Attributes. The Define Informative Note Attributes window opens, with the Informative Note Attributes tab selected. This tab shows detailed information about one Informative Note Attribute, and is the window for defining new attributes. Click the Multi Display Informative Note Attributes tab to view several attribute records at once.
The Properties block contains the essential information about the attribute: its name, type, and other settings that control its use in TMS.
To define the attribute's properties, from either tab of the Define Informative Note Attributes window:
In the Label field, enter a name for this attribute. The label provides context about what sort of information you store in Informative Notes based on this attribute. The label text appears as a header wherever the Informative Note appears in TMS.
From the Type list, choose Standard, URL, Workflow, or Algorithm. See "Type of Attribute" for details about each of these choices.
The Derivable list choice determines whether external systems will be able to derive Informative Notes that you define based on this attribute. Choose Yes to enable external systems to derive this Informative Note data, or No to prevent this derivation.
Select the Updateable? box if you want users to be able to update Informative Notes based on this attribute.
Select the LOV Validation box if you want TMS to limit the values for a particular Informative Note to those defined in the SQL statement you enter in the LOV Statement field in the Details panel below. This setting is not applicable if no LOV is generated from the LOV statement, and is not relevant for Informative Note Attributes of data type Memo or of attribute type URL.
From the Data Type list, choose one of the four available Informative Note data types: Char (character), Date, Memo, or Number. Informative notes of type Memo are stored in the database as character large objects.
Attribute types Algorithm and URL should always have a data type of Char.
In the Entry Length field, enter a maximum length for Informative Notes based on this attribute. Entry length is irrelevant for Informative Notes of data type Memo or Date. If you do not enter a value in this field for a Char or Number Informative Note, TMS supplies the default value of 300 characters.
Save, or navigate to the Details block on the Informative Note Attributes tab to enter attribute details. See "Defining the Details for the Informative Note Attribute".
Attribute details are optional, but you can create a more specific and useful Informative Note Attribute by specifying them for some applications.
To define attribute details:
In the Attribute Code field, you can enter a mixed-case code that you can use to link this Informative Note Attribute to an attribute defined in a vendor's dictionary.
In the Short Name field, you can enter a unique value for the short name of this Informative Note Attribute. TMS allows short names containing up to ten bytes of alphanumeric text. If you leave this field blank and save the record, TMS supplies a default, unique value.
In the Description field, you can enter user-defined text about this Informative Note Attribute.
In the LOV Statement field, you can enter the SQL statement you want to use to populate a list of values for Informative Notes based on this attribute. The system limits values to those in the LOV only if you select the LOV Validation? box, described in the above section, "Defining the Properties for the Informative Note Attribute".
Save. TMS commits this Informative Note Attribute to the database, which enables you to create Informative Notes based on this attribute.
After you have defined an Informative Note Attribute, specify the dictionary or dictionaries with which it is appropriate for use, and the item—term, relation, term history, dictionary, or filter dictionary algorithm—with which it is appropriate. When users define Informative Notes, the system allows them to select only Informative Note attributes that you define as appropriate in this window.
From the Define Informative Note Attributes window, with the Informative Note attribute displayed (or, in the multi-display tab, selected), click Dictionary Attrs. The Define Dictionary Informative Note Attributes Dictionary (APPROVAL) window opens.
Click in the topmost empty row. The fields in the row become enterable. If you need more rows than are displayed, select Insert from the Record menu.
In the Base/Filter Dictionary From column, click the ellipsis (…) on the right side of the field to display the list of values, which includes all base and filter dictionaries defined. Select a dictionary in which you want to be able to use the selected Informative Note attribute.
If the Informative Note attribute is of type Algorithm, TMS displays only active filter dictionaries.
In the Base/Filter Dictionary To column, click the ellipsis (…) on the right side of the field to display the list of values, which includes all base and filter dictionaries defined. In most cases, select the same dictionary you selected in the Base/Filter Dictionary From column. However, if you want to use the attribute for cross-dictionary relations, select the reference dictionary.
If the Informative Note attribute is of type Algorithm, you must select the same dictionary you selected in the Base/Filter Dictionary From column. For other types of Informative Notes, you can select a different dictionary only if there is a cross-dictionary link or a filter dictionary link defined for the two dictionaries and only if Applies To is set to Relation (see next step); see "Filter Dictionaries" and "Defining a Cross-Dictionary Link".
In the Applies To column, select the type of item for which the user can create Informative Notes from this attribute in this dictionary or dictionary combination.
Note:
If an attribute is appropriate for use with more than one item, create a record (add a line) for each one.Content. If an attribute is appropriate for use in creating an Informative Note on a term, select Content. If the Informative Note attribute is of type Algorithm, you must select Content.
Relation. If an attribute is appropriate for use in creating an Informative Note for a relation between terms, including terms in different dictionaries, select Relation.
Term History. If an attribute is appropriate for applying to term history data; for example, to comment on a change in term status; select Term History. See "Term Statuses" for further information.
Only Informative Note attributes of type Workflow and data type Memo can be used for term status Informative Notes.
Dictionary. If an attribute is appropriate for use in creating a dictionary-wide Informative Note, select Dictionary.
In the Status column, leave Active selected.
Change to Retired later, if you want to prevent any further Informative Notes from being created in this dictionary or dictionary combination with this Informative Note attribute.
Save.
You can delete Informative Note Attributes, provided there are no Informative Notes in the repository based on that attribute. To delete an Informative Note Attribute, navigate to its record in either tab of the Define Informative Note Attributes window, then delete the record.
When you define an Informative Note for an entire dictionary, each term record in the dictionary inherits the Informative Note as well. This inheritance is useful if, for example, you want to associate each term in a dictionary with a URL that contains its name. By defining a single, dictionary-wide Informative Note that includes a variable for the term name, you can create context-sensitive Informative Notes for each term in the dictionary and maintain these notes with a single definition.
Note:
Relation records do not inherit Informative Notes from their dictionaries.You can define Informative Notes only for strong dictionaries of Active status. You can also define Informative Notes for individual data records. For more information, see either "Creating Informative Notes for Terms and Relations" or "Using the Status/Notes Pop-up Window".
The process of defining a dictionary-wide Informative Note has two steps:
You can create Informative Notes for Active dictionaries only. To begin defining a dictionary-wide Informative Note Attribute:
Open the Define Dictionaries window and select a dictionary.
Click the Informative Notes button. The Maintain Dictionary Informative Notes window opens.
In the Informative Note field, click the ellipsis (…) button. TMS opens the Informative Note Attributes list of values window.
Choose an attribute from the list of values, and click OK. TMS populates the Informative Note and Type fields with your attribute selection.
In addition to user-defined Attributes, the list of values includes RDC Action Text. Select this Attribute to create a label for the Special Listings tab in Oracle Clinical Remote Data Capture Release 4.5.3 and above.
There are three different definition strategies, depending on the attribute type and data type for the Informative Note you are defining. You cannot define dictionary Informative Note based on Workflow attributes.
Note:
For information on Informative Notes of type Algorithm, see "Defining Informative Notes for SMQ Algorithms".For each Informative Note of this attribute type and data type, you can enter the Informative Note information directly into the Value field. The length and data type that you can enter here is dictated by the Informative Note Attribute, and as you enter data in the Value field, TMS validates the data type and length for your entry.
To complete this type of dictionary-wide Informative Note, enter the text of the note and save. TMS validates and saves the Informative Note for this dictionary.
You can store CLOBs for either STANDARD or WORKFLOW Informative Notes, as long as the attribute contains the data type Memo.
When you select an attribute with data type Memo from the Informative Notes Attributes window, TMS displays the word Memo in blue type in the Value field. To enter the contents of the CLOB:
Double-click the word Memo in this field, or select the drill-down option. TMS opens the Memo (Attribute Name) window (Figure 7-2).
Enter or paste the contents you want to store in this field.
Click OK. TMS closes the Memo window.
Save. TMS validates and saves the Informative Note for this dictionary.
Unless you preface a URL entry with a protocol (http:// or ftp://, for example), TMS assumes that the document location you enter is relative to the CGI directory on the TMS Web Server. The CGI directory is the location on the TMS Web Server of the TMS executable, ifweb60.exe. You can refer to the CGI Directory Mappings page to view the CGI directory for your Web Server:
Connect to http://computername.server/WebDB/admin_/listener.htm
Scroll down to the CGI Directory Mappings.
Find the physical directory that corresponds to the virtual directory location /dev60cgi/.
TMS uses this location--typically oracle_home\tools\web60\cgi--as a reference point for internal documents. Thus, if you enter a value of readme.htm as the value of a URL Informative Note, then click the URL while browsing this Informative Note, TMS launches a Web browser window and attempts to connect to the following address:
http://computername.server/dev60cgi/readme.htm
This strategy enables you to link terms and relations to internal documents via URL Informative Notes. To associate external Web sites such as www.yahoo.com with terms or relations, enter values such as http://www.yahoo.com.
If you have TMS integrated with Oracle Clinical and are using Remote Data Capture (RDC) Release 4.5.3.10 or above, you can use the RDC Special Listings page to display information about a patient's adverse events, concomitant medications, or other data classified in TMS.
You use a special type of Informative Note to specify the text of the item in the drop-down list on the Home and Casebooks pages for a particular dictionary. By default, this text is: Review TMS_Dictionary_name / DCM_name. On the Special Listings page itself the same value (without "Review") appears in the Listing Type drop-down.
You can replace the dictionary name with text that would be more meaningful to RDC users, such as Adverse Events or Concomitant Medications, so that the item in the drop-down list would be "Review Adverse Events / DCM_Name," for example, rather than "Review MedDRA / DCM_Name."
To do this:
In the Informative Notes field, select RDC Action Text from the list of values.
In the Value field, enter the text you want to appear in the RDC drop-down list, such as Adverse Events or Concomitant Medications.
Save.
Note:
You can define only one Informative Note of Attribute RDC Action Text for each dictionary. The value text is used in RDC for every study and domain where the dictionary is used.You can also nest variables in URL Informative Notes, to substitute information about a term record in the text of the URL. For example, if you include the variable %TERM% in a dictionary-wide URL Informative Note, TMS substitutes the term name in the text of the URL. Thus, when you define the dictionary-wide URL Informative Note http://search.yahoo.com/bin/p=%TERM%, the term record Massachusetts inherits http://search.yahoo.com/bin/p=Massachusetts as an Informative Note. TMS enables you to launch a browser window from the Browse Informative Notes window that connects to this URL.
The Informative Notes window allows you to substitute the following variables into URL values. These values correspond to columns in the TMS_DICT_CONTENTS table for term records or the TMS_DEF_DETAILS table for Informative Note Attributes.
| TERM | CATEGORY |
| VALUE_1 | VALUE_3 |
| DICT_CONTENT_ID | DICT_CONTENT_ALT_CODE |
| DEF_DETAIL_ID | DICT_INFO_HDR_ID |
| TERM_UPPER | COMMENT_TEXT |
| VALUE_2 | VALUE_4 |
| DICT_CONTENT_CODE | LABEL_TEXT |
| LABEL_TEXT_UPPER |
To enter a URL Informative Note, click in the Value field and enter the internal or external address for the related document. You can append variable values to the URL value from the URL Parameters window. While the cursor is in the Value field, press F9, or select Edit and then List of Values to browse the available options. When you select a variable and click OK, TMS appends %variable% to any text in the Value field. You can also cut and paste variables in the Value field to create a valid URL.
You can use a specialized, predefined Informative Note Attribute called Dictionary Version to assign a version number to a dictionary. To define the version for a dictionary, using an Informative Note:
Open the Define Dictionaries window and select a dictionary. You can define a version number for base or virtual dictionaries.
Click the Informative Notes button. The Maintain Dictionary Informative Notes window opens.
In the Informative Note field, click the ellipsis (…) button. TMS opens the Informative Note Attributes list of values window.
Choose Dictionary Version from the list of values, and click OK. TMS populates the Informative Note and Type fields with your attribute selection.
Enter the version number in the Value field.
(Optional) Enter a status to define this version number further.
Save. TMS validates the entry and saves the Informative Note, returning you to the Define Dictionaries window.
|
 Copyright © 1999, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
