Modifying Repository Data in the Maintain Repository Data Window
In the Maintain Repository Data window, you can perform two basic types of dictionary data maintenance:
Parent topic: Repository Maintenance
Maintaining Terms, Relations, and VTAs
You can add company and domain terms to an external dictionary within its hierarchical structure (company terms and company relations are available to all TMS domains; domain terms and domain relations are available only within the TMS domain in which you define them). You can define strong relations between VTAs, company and domain terms, and external terms (terms supplied in an external dictionary such as MedDRA or WHO-Drug).
You can modify or delete company and domain dictionary terms, and their relations. See Deleting Terms from a Dictionary and Modifying a Term.
Note:
TMS only allows you to create an external relation between the terms in a strong dictionary when the level relation is defined as mandatory.
Verbatim Term Assignments (VTAs) are represented by their verbatim term and Verbatim Term Individuals (VTIs) are represented by their verbatim term of a single source term and auxiliary information (optional). VTAs may be available either globally or only in a TMS domain (see Global and Domain VTAs), and inherit the global/domain status of their verbatim term. VTIs are available only in a TMS domain (see Nonunique Coding Level Dictionaries).
When you save your changes, TMS creates a new record in the predict tables for the term or relation to be inserted, updated, or deleted. When you requery you can see both the current record from the production tables and the new record in the predict tables. When you activate data, records that pass Activation move from the predict to the production tables, and the old production records are no longer current. Terms and relations that do not pass Activation remain in the predict tables with an error message.
This section includes general instructions for tasks, followed by detailed information on the fields in each block of the window, as follows:
Adding and Deleting Relationships Between Terms
To add a relationship between terms:
-
Highlight the lower level term in the Current Level block.
-
In the upper block, either enter the upper level term or choose it from a list of values.
-
Save.
Note:
You can also modify information about a relation, such as the Relation Status or Relation Comment, by editing these fields in the upper block.
You cannot directly change the type from VTA to VTI or vice versa. If term uniqueness changes and such a change is legitimate, you must delete the existing relation and create a new one.
To delete a relationship between terms:
- Highlight the lower level term in the Current Level block.
- Highlight the higher level term in the upper block.
- Either select Record and then Delete, or press Shift+F6.
- Save.
Deleting relations from established dictionaries can be more complex because dictionary rules require mandatory relations between levels.
Parent topic: Maintaining Terms, Relations, and VTAs
Deleting Terms from a Dictionary
When you delete a term from a dictionary, you also delete all relations from that term to other dictionary terms. Before activating data after deleting a term, you may want to examine pre-dictionary DML statements to reassign the relations before they are deleted.
Further, if you delete a term from a dictionary's classification level (or group level), TMS automatically marks all associated VTAs and VTIs for deletion as well. This deletion applies both to automatically and manually classified VTAs and VTIs. The verbatim terms that had mapped to this classification level term will become omissions upon the next Synchronization.
To delete a term and the relations to it from a dictionary, highlight the term and either select Record and then Delete, or press Shift+F6, then save. TMS creates a delete statement for the term and its relations in the pre-dictionary tables.
Note:
If you accidentally delete the wrong term or relation, you can undo the change by either requerying or by exiting the window before you save the changes. When exiting, TMS prompts you to save your changes; click No in these situations.
Parent topic: Maintaining Terms, Relations, and VTAs
Adding a Term to a Dictionary Level
To add a term to the desired dictionary level:
After adding a term to a dictionary level, you can create relations between the new company or domain term and terms in related levels. Where the dictionary structure defines level relations as mandatory, you must create a relation. Where the dictionary structure defines a level relation as requiring a Primary Link, you must create a Primary Link. See Define Strong Relations to Terms in Other Levels.
Parent topic: Maintaining Terms, Relations, and VTAs
Modifying a Term
To modify a term:
- In the tree structure, highlight the level of term you want to modify.
- In the Current Level block in the middle of the screen, query for the term.
- Highlight the term.
- Fill in the fields as necessary to redefine the term the way you want. For descriptions of the fields, see Current Level Block Fields.
- Save. TMS enters the updated term in the predict contents table. You must activate the current Activation Group before you can use the new term. See Activating Data.
Parent topic: Maintaining Terms, Relations, and VTAs
Define Strong Relations to Terms in Other Levels
You can define a link, or relation, between terms in related levels. Relations between terms must follow the rules defined for the relation between their levels:
- If the level relation is defined as Mandatory, you must create a relation between the new term and at least one term in each level with a mandatory relation to the current level.
- If the relation between the two levels is defined as One-to-one, you can define only one relation. If the relation is defined with Many Cardinality on the side of the noncurrent level, you can create relations with any number of terms in the noncurrent level.
- If the relation is defined as requiring a Primary Link, you must define a Primary Link (this applies only to relations defined with Many Cardinality on the side of the noncurrent level).
Reading Defined Level Relations
You can see the level relation rules defined for the dictionary in the tree structure on the left side of the window.
- Optionality. The tree structure shows mandatory relations between levels with a solid line; optional relations have a dotted line. A relation may be optional at one end and mandatory at the other.
- Cardinality. The tree structure shows Many Cardinality (a level relation
where a term in one level may have a relation with
more than one term in another level) with a
branch; if only one relation is allowed, the
relation line is not branched.
The following diagram shows a level relation that is Mandatory and Single Cardinality on the parent level end and Optional and Many Cardinality on the child level end; that is, terms in the child level must have a relation to only one term in the parent level, and terms in the parent level may or may not have one or more relations with terms in the child level.
- Primary Links. If many relations are allowed but a Primary Link to one of them is required, TMS displays a p above the relation icon. Similarly, if a Primary Path link is required, TMS displays a pp above the relation icon.
Defining Domain and Company Primary Links
You must define a Primary Link between a company or domain term and a term in another level where the level relation requires a Primary Link. If the lower-level term is a domain term, the Relation Subtype is automatically entered as Domain, and the Primary Link applies only within the current domain, because the term exists only in the current domain.
The following rules apply to creating Primary Links (with the PL? box) between domain terms and company or external terms:
- A Primary Link between a lower-level domain term and a higher-level domain term (in the same domain) is allowed. The Primary Link applies only to the domain where the terms exist.
- A Primary Link between a lower-level domain term and a higher-level company or external term is allowed. The Primary Link applies only to the domain where the term exists.
- A Primary Link between a lower-level company or external term and a higher-level company or external term is allowed. The Primary Link applies to all domains.
- A Primary Link between a lower-level company or external term and a higher-level domain term is not allowed.
You can override a Global Primary Link (PL) within a particular domain by defining a Domain Primary Link (DPL), using the DPL? box. You can use this box only for company or external terms that already have a Global Primary Link defined, and only for a relationship that is already activated.
(You cannot create a Primary Link in a relation of subtype Domain between two company or external terms. However, you can create a relation of Subtype Company or External, activate the relation, and then define a Domain Primary Link (DPL) between the terms.)
Defining a Relation Between Terms
You can create relations only between terms that have already been loaded or defined and activated. You can create terms only in the Current Level block. To define a strong relation, take the following steps:
Parent topic: Maintaining Terms, Relations, and VTAs
Current Level Block Fields
The Current Level block, in the middle of the Maintain Repository Data window, provides the following term information.
-
Level_Name: Under this heading, which is the name of the dictionary level, the system displays a term name in each row. Free-form text of up to 300 alphanumeric characters.
-
DML: Display-only. The transaction to be performed on the term. When you save changes, TMS enters a value here (for update and delete transactions, you cannot see the new value until you requery). The next time you run Activation on this Activation Group, TMS will try to perform this transaction on this term.
-
Level: The short name of the level to which the term belongs.
-
Type: Displays the term type: Dictionary Term, VTA, or VTI.
-
Code: Optional. Enter a value here according to your company's policy. This field is designed to serve as the primary key within this dictionary; must be unique within the dictionary. Free-form text; up to 30 alphanumeric characters. You can create an LOV and validation for this field in the Details window; see Defining Level Details.
-
Alt Code: Optional user-defined field. You can create an LOV and validation for this field in the Details window; see Defining Level Details. Indexed. Designed to accommodate a TMS-wide unique ID. Free-form text up to 30 alphanumeric characters.
-
Sub Type: TMS creates new terms in dictionary levels as Company terms unless you deselect Glb?, in which case TMS creates them as Domain terms. TMS creates new terms in the Verbatim Term Level as Accepted unless you choose Misspelled from the Sub Type list.
See Classification Concepts, Misspelled VTAs and VTIs for more information.
-
Glb?: (Global?) If selected, this term is available in all domains. If not selected, it is either available company-wide or only in the current domain, depending on the term's subtype.
-
Appr?: (Approved?) This option has a somewhat different meaning depending on whether it refers to a VTA or a dictionary term.
-
If selected for a VTA, the VTA is approved and does not require manual approval. TMS can use the VTA in Autoclassification.
-
If selected for a dictionary term at the classification level, the term is valid in the current dictionary version and approved as a potential classification in all domains.
Note:
It is possible to allow classification to nonapproved dictionary terms in a specific dictionary domain. See Assigning a Dictionary to a Domain for more information.
-
-
Status: Optional. Enter a value to describe the status of the term.
-
Category: Optional. MedDRA supplies categories for some of its terms, such as Diagnosis, Adverse Event, or Undefined Procedures. These are displayed here. For other dictionaries, you can assign categories to terms according to your company's policies. Free-form text; up to 65 alphanumeric characters. You can create an LOV and validation for this field in the Details window; see Defining Level Details.
-
ID: Display-only. For each term, TMS creates an ID that is unique across TMS and serves as the primary key in TMS.
-
Comment Text: Optional. Use for any information that would be helpful to others using the dictionary. For example, "This drug should be included in the next version of WHO-Drug, and I have submitted it," or "This may seem wrong, but I've checked with the investigator." Free-form text; up to 200 alphanumeric characters.
-
Error Msg: Display-only. Populated by TMS during Activation. If TMS cannot activate this term, TMS leaves it in the predict tables and enters an error message in this field giving the reason(s) it failed Activation.
-
Created By: Display-only. The user ID of the person who added the current term or executed the load script.
-
Creation: Display-only. The creation timestamp for the current term.
-
Valid Until: Display-only. TMS uses this value to maintain an audit trail of terms. When a term is created, it receives a default end timestamp in the distant future (currently August 3500). When a term is updated, a new term record is created and the old term's end timestamp is set to the creation timestamp of the new term. This field is used to recreate the dictionary at a given point in time.
-
Deleted By: Display-only. The TMS user who deleted this term, if any.
-
Trans.Id.: Not used in this release.
-
Values 1-4: User-definable fields. Use these fields according to your company's policies and study design. You can define up to four fields, their data type and length, and LOV to appear here. See Defining Level Details. If no values are defined for these fields, they will not appear on the screen.
When you enter data for a term record in any of the Value 1-4 fields, you can also choose <null> from the LOV.
Parent topic: Maintaining Terms, Relations, and VTAs
Upper Block Fields
The upper block provides the following term and relation information:
-
Term: The name of the term. Free-form text of up to 300 alphanumeric characters.
-
Relation: The named relation instantiated between the current term and the term in this upper block row. Displays STRONG for strong relations.
-
DML: Display-only. The transaction to be performed on the relation. When you save changes, TMS enters a value here (for update and delete transactions, you cannot see the new value until you requery). The next time you run Activation on this Activation Group, TMS will try to perform this transaction on this relation.
-
Level: Display-only. The Dictionary Short Name and Level Short Name of the dictionary and level to which the term belongs.
-
Code: Optional, user-defined field. Enter a value here according to your company's policy. This field is designed to serve as the primary key within this dictionary; must be unique within the dictionary. This field is free-form text, up to 30 alphanumeric characters, and indexed. You can create an LOV and validation for this field in the Level Details tab window of the Define Dictionaries form; see Defining Level Details for detailed instructions.
-
PL?: The Primary Link?/Primary Path Link? box, if selected, denotes that the current term is either a Primary Link or Primary Path Link this level for the current term. Refer to the relation line between the levels in the TMS tree structure to determine the relationship between the selected levels.
-
DPL?: (Domain Primary Link?) If selected, this term is the Primary Link in this level for the current term in the current domain.
-
RGlb?: (Relation Global?) If selected, this relation is valid across all domains.
-
Type: Relation Type. In general, the relation inherits the type of the higher-level term. The Domain Restricted type is used for relations that have been defined as Domain Primary Links and have not yet been activated.
-
Sub Type: Relation Subtype. By default, the relation subtype is Company. The relation subtype cannot be modified. You would need to delete the existing record and create a new record in order to make a change to the relation subtype.
If the subtype is Accepted or Misspelled, the relation is a VTA; you can change this subtype at any time. You can also change a VTA's status from Global to Domain or vice versa in the Promote/Demote window under the VTA Maintenance menu.
-
R. Status: (Relation Status) Optional. Enter a value to describe the status of the relationship.
-
R. Trans. Id: (Relation Transaction ID) Not used in this release.
-
Alt Code: Optional, user-defined field. You can create an LOV and validation for this field in the Details window; see Defining Level Details. Indexed. Designed to accommodate a TMS-wide unique ID. Free-form text up to 30 alphanumeric characters.
-
ID: Display-only. For each term, TMS creates an ID that is unique across TMS and serves as the primary key in TMS.
-
Appr?: (Approved?) Display-only, refers to the term on this line, not the relation. This setting has a somewhat different meaning depending on whether it refers to a VTA or a dictionary term. Selected by default.
If selected for a VTA, the VTA is approved; TMS can use the VTA in Autoclassification and manual approval is not required.
If selected for a dictionary term, the term is approved as a potential classification. If you are adding one or more domain or company terms that you want to use instead of an external dictionary term, you can clear the Appr? box for the external dictionary term.
-
Category: Optional. MedDRA supplies categories for some of its terms, such as Diagnosis, Adverse Event, or Undefined Procedures. These can be displayed here. For other dictionaries, you can assign categories to terms according to your company's policies. Free-form text; up to 65 alphanumeric characters. You can create an LOV and validation for this field in the Level Details tab window of the Define Dictionaries form; see Defining Level Details for detailed instructions.
-
Relation Comment: Optional. Use for any information that would be helpful to others using the dictionary. Free-form text; up to 200 alphanumeric characters.
-
Relation Error Msg: Display-only. Populated by TMS during Activation. If TMS cannot activate this relation, TMS leaves it in the predict tables and enters an error message in this field giving the reason(s) it failed Activation.
-
Relation Created By: Display-only. The user ID of the person who added the current term or executed the load script.
-
Relation Created: Display-only. Timestamp for the creation of this relation.
-
Relation Valid Until: Display-only. TMS uses this value to maintain an audit trail of relations. When a relation is created, it receives a default end timestamp in the distant future (currently August 3500). When a relation is updated, a new relation record is created and the old relation's end timestamp is set to the creation timestamp of the new relation. This field is used to recreate the dictionary at a given point in time.
-
Relation Deleted By: Display-only. The TMS user who deleted this relation, if any.
-
Entry Ts: Display-only. The creation timestamp for the current term.
-
Values 1-4: User-definable fields. Use these fields according your company's policies and study design. You can define up to four fields, their data type and length, and LOV to appear here. See Defining the Dictionary Levels. If no values are defined for these fields, they will not appear on the screen.
Parent topic: Maintaining Terms, Relations, and VTAs
Resolving High-Level Omissions
When a derivable term is not related to any terms in the next higher derivable level, TMS cannot derive a term from the higher level, and creates a high-level omission.
TMS does not return high-level omissions to the external system as discrepancies. It creates these omissions within TMS and returns values to the external system for all the derivable levels possible. When a high-level omission is resolved in TMS, the missing high-level value is derived to the external system during the next data exchange (Batch Validation in Oracle Clinical).