Dictionary Types

You can define the following types of dictionaries:

• Strong Dictionaries
  
• Weak Dictionaries
  
• Virtual Dictionaries
  
• Filter Dictionaries
  
• Nonunique Coding Level Dictionaries
  
• Classifying High-Level Terms Based on Indication
  
• Substitution Terminology Dictionaries
  

Strong Dictionaries

A strong dictionary definition in TMS consists of a fixed number of hierarchical levels with defined relations between the levels. You store every dictionary term in a particular level and define relations from each term to terms in other levels, according to the relations you have defined for the levels themselves. This type of TMS dictionary definition is appropriate for external dictionaries such as MedDRA and WHO-Drug.

Strong dictionaries can serve as the base for creating virtual dictionaries and filter dictionaries; see Virtual Dictionaries and Filter Dictionaries.

For more information, see Planning Strong Dictionary Structure.

Weak Dictionaries

Some external dictionaries, such as SNOMED, require a different type of structure, one that is dynamically created by relations between terms. TMS supports these with weak dictionaries and named relations between terms.

Where strong dictionaries have fixed hierarchies, represented by levels, weak dictionary have dynamic hierarchies, which are variable. For example, a strong dictionary with four levels from the coding level to the highest derivation level will only have four terms in a hierarchical chain:

• Level 1 - Term 1
• Level 2 - Term 2
• Level 3 - Term 3
• Level 4 - Term 4

A weak dictionary does not depend on dictionary levels to identify the hierarchy. The hierarchical structure of the dictionary is defined by the relationships permitted and used in the dictionary. Named relations describe the connection between terms. For example, you can use the named relation Narrower term to link the terms "aspirin" and "pain reliever," or the named relation Is part of to define a hierarchical series of relations as follows:

• Term 1 - is part of - Term 2
• Term 2 - is part of - Term 3
• Term 3 - is part of - Term 4
• Term 4 - is part of - Term 5
• Term 5 - is part of - Term 6

In the above example, the number of terms that can be linked in a hierarchical chain is not limited by the number of levels. In fact, all of the terms (1 through 6) are on the same level, and the length of the hierarchical chain is unlimited. Dictionaries with this characteristic are called dynamic.

TMS requires that each dictionary definition have at least one level to contain dictionary terms. If your dictionary is really a collection of dynamic dictionaries, you can define a TMS dictionary level for each component dictionary and fully define the dynamic dictionary within that level. (Do not define level relations as you do in strong dictionaries.) If your dictionary is a single dynamic dictionary, define a single dictionary level for it. You can define named relations between terms in the same or different levels of a weak dictionary, as business needs dictate.

Note:

You cannot code verbatim terms against weak dictionaries because they do not have a specific classification level.

See Defining Named Relations for more information.

Virtual Dictionaries

Base dictionaries usually contain the latest dictionary and verbatim terms, because they are updated on an ongoing basis. These dictionaries are useful for studies that require the most up-to-date dictionary information.

By contrast, virtual dictionaries have defined cut-off dates, after which no dictionary terms can be added. Using a virtual dictionary enables you to continue coding verbatim terms for a clinical study against one version of a dictionary while the base dictionary changes. You can also use virtual dictionaries to view the state of a dictionary's terms and relations for any date in that dictionary's history. Virtual dictionaries can only be based on a single, active base dictionary, from which the virtual dictionary inherits its definition.

To set up a virtual dictionary in TMS, choose a base dictionary (and activate it, if the base dictionary is still provisional), define the virtual dictionary's name and cut-off date, and assign the virtual dictionary to a domain (see Assigning a Dictionary to a Domain).

1. Define and activate the base dictionary on which you want to base the virtual dictionary; see Defining a Dictionary and set it to active; see Setting the Dictionary's Status to Active.
2. Load data into the base dictionary and activate the data; see Loading a Dictionary.
3. With the base dictionary displayed in the Base Dictionary tab of the Define Dictionaries window, click the Virtual Dictionaries tab.
4. From the Record menu, choose Insert Record. The system displays values for most fields that are inherited from the base dictionary. You can modify the Short Name, Name, and Description to make them more meaningful.
5. Define a Cut-off Date. All terms current at the point in time you specify will constitute the virtual dictionary. You cannot change the cut-off date after saving. Click in the Cut-off Date field. If other virtual dictionaries have been created for the same base dictionary, their cut-off dates are available in the LOV. If not, you can enter the date using the format:

   DD-MON-YYYY HH:MM:SS

   for example, 01-NOV-2006 10:01:15

   You can enter the date portion only and the system will enter a time of midnight.

6. If a Release Label has already been associated with the timestamp you selected, the system displays it in the Release Label field. You can modify it if necessary. Save.
7. When you are satisfied with your virtual dictionary definition, set its Status to Active and Save.
8. You can then assign an Informative Note of type Dictionary Version to the virtual dictionary by clicking the Info Notes button. See Defining Dictionary-wide Informative Notes for instructions.

To browse the state of a dictionary at a particular point in time, adjust the data currency to view the terms that were current in a dictionary at any date in the dictionary's history. To view such a representation of the dictionary, launch the Browse Repository Data form and enter the date in the appropriate field at the top of the window.

Filter Dictionaries

This section includes:

• About Filter Dictionaries
  
• Using MedDRA SMQs in TMS
  
• Filter Dictionary Rules
  
• Defining Informative Notes for SMQ Algorithms
  
• Maintaining Filter Dictionaries
  

About Filter Dictionaries

Standardized MedDRA Queries (SMQs) are designed to aid in the identification and retrieval of case safety reports in clinical studies. The MedDRA Maintenance and Support Services Organization (MSSO) defines SMQs as follows:

SMQs are groupings of terms from one or more MedDRA System Organ Classes (SOCs) that relate to a defined medical condition or area of interest. They are intended to aid in case identification. The included terms may relate to signs, symptoms, diagnoses, syndromes, physical findings, laboratory and other physiologic test data, etc., related to the medical condition or area of interest. Lowest Level Terms (LLTs) that are not subordinate to an included Preferred Term (PT) are excluded.

See the figure below for an example of a MedDRA SMQ.

TMS provides filter dictionaries as a generic way to support SMQs and potential similar features for other standard dictionaries. You define, load, and maintain a filter dictionary in the same way you define, load, and maintain a base dictionary such as MedDRA. You must define a filter dictionary as a strong dictionary with at least one level and link the filter dictionary to one and only one base dictionary. In addition, before you load MedDRA SMQs you must define broad and narrow named relations and algorithm Informative Notes (see below).

MedDRA SMQs may use one or more of the following design features:

• Broad and Narrow. SMQ relations with dictionary terms may be identified as broad or narrow. Narrow terms are highly likely to represent the condition of interest while broad terms help to identify all possible cases, including some that may prove to be of little or no interest. A broad search retrieves broad terms. A narrow search retrieves narrow terms.

  To support broad and narrow SMQ searches in TMS, define and load broad and narrow named relations from SMQ terms to base dictionary terms.

• Algorithm. Algorithms within SMQs are used to further define combinations of specific terms based on rules defined in an algorithm that can be processed programmatically during a search operation.

  To support SMQ algorithms, define an Informative Note of type Algorithm for SMQ terms with algorithms; see Defining Informative Notes for SMQ Algorithms.

  MSSO provides predefined categories of terms called A…F. You must load these categories with SMQ filter dictionary terms and store them in the Status column of the table TMS_DICT_RELATIONS. Some SMQ algorithms use these categories.

• Hierarchy. Some SMQs are a series of queries related to one another in a hierarchical relationship similar to the hierarchical structure of MedDRA itself.

  To support hierarchical SMQ searches in TMS, load SMQ terms into different levels of the filter dictionary with relations between the terms.

Figure 6-1 Figure 6-1 Acute Pancreatitis SMQ Terms and Algorithm

Virtual Dictionaries of Filter Dictionaries

You can create a virtual dictionary of a filter dictionary—that is, a filter dictionary at a specific point in time. The filter dictionary's virtual dictionary must have the same cut-off date and time as an existing virtual dictionary of its base dictionary.

For example, given the following dictionary definitions:

• MedDRA SMQ is the filter dictionary of MedDRA
• MedDRA Version 7 is a virtual dictionary of MedDRA with the cut-off date 8/1/2006 00:00:00

you can define a virtual dictionary called MedDRA SMQ Version 7 of MedDRA SMQ with the same cut-off date as virtual dictionary MedDRA Version 7: 8/1/2006 00:00:00. It will reference terms in virtual dictionary MedDRA Version 7.

In other words, if you are using a virtual dictionary for coding and you want to use a filter dictionary with it, you must create a virtual dictionary of the filter dictionary with the same cut-off date as the virtual dictionary you are using for coding.

Using MedDRA SMQs in TMS

To use MedDRA SMQs in TMS, do the following:

1. Define a filter dictionary for MedDRA SMQs; see Filter Dictionary Rules.
2. Specify its base dictionary in the Dictionary Links tab, using the link type Filter Dictionary Of. For the MedDRA SMQs filter dictionary, the base dictionary must be a MedDRA dictionary. See Defining Filter Dictionary Links.

   Note:

   Filter dictionaries inherit their domain assignments from their base dictionary.

3. Define two named relations of type Standard with Many Cardinality, each with no reciprocal relation defined, to support broad and narrow relationships. Include the exact short name you define for these named relations in your MedDRA SMQs load script; see Defining Named Relations.

   Include the DEF_NAMED_REL_ID of these named relations in your MedDRA SMQs load script.

4. For the broad and narrow named relationships you have defined, create a dictionary named relationship record from the filter dictionary to the base dictionary; see Defining Dictionary NRLs.
5. Define Informative Note attributes of type Algorithm for SMQ algorithms; see Defining Informative Notes for SMQ Algorithms..
6. Create a load script and load MedDRA SMQs; see Loading a Dictionary.

   You can use the load script to load Algorithm-type Informative Notes and Broad and Narrow named relations or define them manually; see Defining Informative Notes for SMQ Algorithms and Creating Named Relations Between Terms.

Filter Dictionary Rules

See Defining a Dictionary for detailed instructions on how to define a dictionary. Select Filter as the Dict Type and observe the following rules for filter dictionaries:

• Language. Filter dictionaries and their base dictionaries must have the same language attribute setting.

• VT Level Required. Uncheck. Filter dictionaries cannot have a VT level.

• Folder Type. Filter dictionaries must be designated as Strong type.

• Dictionary Link. A filter dictionary must have one and only one "Filter Dictionary Of" dictionary link to a base dictionary. This dictionary link defines the fact that the filter dictionary will contain only terms defined in the base dictionary.

  A base dictionary can have one and only one "has Filter Dictionary" link to a filter dictionary.

• Virtual Dictionaries. Filter dictionaries can have associated virtual dictionaries. These "versions" of filter dictionaries must have the same cut-off date as an existing virtual dictionary of the filter dictionary's base dictionary.

• Domains. Filter dictionary domains are maintained by TMS. A filter dictionary inherits all the domains of its base dictionary. You can see a filter dictionary's domains in the Define Domain Dictionaries form, but you cannot change them.

Defining Informative Notes for SMQ Algorithms

Some MedDRA SMQs include algorithms that return refined search results. You can use these algorithms in TMS to search for source terms that report relevant symptoms or diagnoses.

To use SMQ algorithms in TMS you must do the following:

• Create one Informative Note attribute of type Algorithm; see Defining Informative Note Attributes.

• Create an Informative Note of type Algorithm for each SMQ filter dictionary term with an algorithm defined, either manually (see Creating Informative Notes for Terms and Relations) or as part of the load script; see About Load Scripts.

To support MedDRA SMQs, include the algorithm defined by MSSO for the SMQ filter dictionary term, but transform the format of the algorithm so that TMS can execute it. For example, in MedDRA 9.0, the SMQ algorithm defined by the MSSO for "Acute pancreatitis (SMQ)" is:

A or (B and C)

where A…F are categories of terms predefined by MSSO. You must load these categories with SMQ filter dictionary terms and store them in the Status column of the TMS table TMS_DICT_RELATIONS.

To translate this into a format that TMS understands, replace "or" with "UNION", replace "and" with "INTERSECT", and add the column name of the relations table that stores the SMQ category:

status = 'A' UNION (status='B' INTERSECT status='C')

Note:

You can substitute your own algorithm if you prefer. However, each term can have only one Informative Note of type Algorithm.

Maintaining Filter Dictionaries

Maintain filter dictionaries as you do base dictionaries:

• Maintain Repository Data. Use the Maintain Repository Data window to maintain terms within a filter dictionary. In the lower block, the R. Status column contains the SMQ category of the target term, which is used in SMQ algorithms; see Modifying Repository Data in the Maintain Repository Data Window.

• Repository Authoring. Maintain named relations to base dictionary terms in the Repository Authoring window; Using the Repository Authoring Window.

From both windows you can click the Informative Notes button to navigate to the Maintain Informative Notes forms, where you can maintain the SMQ algorithm as well as other Informative Notes; see Creating Informative Notes for Terms and Relations.

Nonunique Coding Level Dictionaries

In WHO-Drug Format C3, many drug names occur more than once in the coding level. They are distinguished from one another by auxiliary information including the country where they are distributed, their pharmaceutical form (for example, tablets or coated tablets), and their strength (for example, the number of milligrams per tablet). In the TMS dictionary definition, each type of auxiliary information (country or strength, for example) is defined as a sublevel of the classification level.

Auxiliary information must be imported from the source data system for each source term as a definition-value pair consisting of a dictionary level and data value; for example, Strength and 500mg. Updates to auxiliary information should be treated as source term updates.

If you are using Oracle Clinical, you can set up question sets to handle multiple input question responses for each source term. In addition to providing auxiliary information about the drug, you can send information about the indication for which the drug is being taken. This is required in cases where the term must be classified differently depending on the indication, or where a different higher level term must be derived depending on the indication. See Classifying High-Level Terms Based on Indication,Defining Question Set Variables, and Classifying Indication Omissions.

The classification of a verbatim term with a specific set of auxiliary information values to a nonunique dictionary term is called a verbatim term individual (VTI), similar to a verbatim term assignment (VTA) for classifications to unique dictionary terms. Both VTAs and VTIs are supported in the same dictionary. 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.

TMS captures and stores sets of auxiliary information values, assigning an ID to each set and reusing it for terms in all dictionaries and domains that have the same combination of auxiliary information values. For example, the first time the source term Carbamazepine is classified to the dictionary term Carbamazepine with auxiliary values Netherlands, coated tablet, and 200mg, TMS creates an ID such as 1000 for the value collection. When a different verbatim term that shares the same values—Netherlands, coated tablet, 200mg—is classified to any drug, TMS uses the same auxiliary information ID for the new VTI. The ID is stored with its values in the Auxiliary Information table, and the ID is included in the Omissions and Source Terms tables.

Autoclassification cannot match a source term to a nonunique dictionary term until a user manually classifies it. After that, if the dictionary is defined to allow autoclassification with auxiliary information, it classifies all occurrences of the same verbatim term with the same auxiliary information to the same dictionary term.

MedDRA also supports classifying the same source term to different dictionary terms. For example, the source term "Migraine Headache" might sometimes be classified as "Headache" and other times as "Migraine."

Classifying High-Level Terms Based on Indication

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 and/or route of administration 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 has manually classified the indication omission, TMS derives all current and future occurrences of the same term for the same dictionary term/indication and route of administration combination. As of release 5.3, TMS will not store the indication with the verbatim term. Instead, TMS will store the indication and route of administration with the dictionary term. Indication and Route of Administration are not mandatory fields. If a verbatim term is assigned to a dictionary term having multiple high level terms with no primary path, an indication omission is created even if both Indication and Route of Administration are null. You can assign a higher level term path for the specified dictionary term.

For example:

Indication	Route of Administration	Dictionary Term (Preferred Term/Synonym)	High Level Term
Cold	Oral	Ibuprofen	OTHER THROAT PREPARATIONS OTHER CARDIAC PREPARATIONS ANTIINFLAMMATORY PRODUCTS FOR VAGINAL ADMINISTRATION PROPIONIC ACID DERIVATIVES ANTIINFLAMMATORY PREPARATIONS, NON-STEROIDS FOR TOPICAL USE
Cough	Oral	Codeine	NATURAL OPIUM ALKALOIDS OPIUM ALKALOIDS AND DERIVATIVES
Eczema	Topical	Desonide	CORTICOSTEROIDS, PLAIN CORTICOSTEROIDS, MODERATELY POTENT (GROUP II)

In Oracle Clinical, you can create a question set variable of type Indication and type of Route to collect the indication and route of administration; see Defining Question Set Variables. If you are using a different external source data system, you can import "Indication" and the indication value as a value pair to support this feature. You can also specify "Route" and the route value along with the indication. Since both indication and route are optional, it is not mandatory to have indication or route to classify an indication omission.

Note:

Indication omissions are not highlighted in Oracle Clinical Data Entry as verbatim term omissions.

Substitution Terminology Dictionaries

Note:

Substitution Terminology dictionary is added for the TMS 5.3 release.

In order to remove stop words or replace abbreviations, prefix, or suffix text string, a substitution dictionary allows you to add stop words, abbreviations, prefix, or suffix text. The Substitution Terminology dictionary contains a level for stop words, abbreviations, prefix, and suffix to be used in Search Object Transformation. The substitution dictionary is a weak dictionary so that additional levels can be added. You may also create your own substitution dictionary.

In Repository Maintenance > Maintain Repository Data, select the Search Object Domain and Substitution Terminology dictionary. TMS provides a set of stopwords, abbreviations, prefix, and suffix which you may modify by insert, update, or delete. The Abbreviations dictionary level contains the Abbreviation and Replace With text columns. When you perform any transaction (insert, update, or delete of a record in the level, the record is stored in the pre-dictionary until you have activated the substitution dictionary. The Substitution Terminology dictionary will have the same behavior as a weak dictionary.