4 Integrating TMS with Oracle Clinical

This section includes:

When Oracle Clinical and Oracle Thesaurus Management System (TMS) are fully integrated, you can classify the raw patient data entered in Oracle Clinical to standard terms from dictionaries such as MedDRA and WHO-Drug.

After a response is collected to a question that is marked for processing by TMS, during the next Batch Validation the response is sent to TMS as a verbatim term. TMS tries to classify the verbatim term using Autoclassification. If that is not possible, TMS creates an omission that must be handled manually and, during the next Batch Validation, Oracle Clinical creates a discrepancy for the response.

After the verbatim term is classified, during the next Batch Validation TMS returns the classification and any other information you have defined (such as term ID, alternate code, or user-defined details) to Oracle Clinical as derived question response values in the same RDCM as the original collected question response. If a discrepancy had been associated with the response, it is automatically resolved.

In addition, Oracle Clinical passes information about the context of each collected question response to TMS, where you can use it to help with manual classification and other tasks. This key information—Patient, Study, Project, DCM, Investigator, Visit, Document Number and Discrepancy ID—remains stored in TMS (see "Defining External System Information in TMS" for more information). If you reclassify a verbatim term in TMS, during the next Batch Validation the system uses the key information to update the derived responses for each occurrence of the term/question response in Oracle Clinical.

To set up Oracle Clinical for integration with TMS, you must define parent questions to collect the response in Oracle Clinical, derived questions to receive values from TMS, and question sets to link the two and specify the information to be retrieved from TMS. You must also associate TMS domains with Oracle Clinical studies or projects.

To define these objects, you must have access to Oracle Clinical windows that appear only when TMS is installed with Oracle Clinical. The following table shows the privilege required to view each window.

Table 4-1 TMS-Related Windows in Oracle Clinical

Window Oracle Clinical Navigation Path Privilege Required

Question Sets

From the Glib menu, select Question Sets, then choose Question Sets

rxc_gl_full

Qry Question Sets

From the Glib menu, select Question Sets, then choose Qry Question Sets

rxc_any

TMS Domain Elements

From the Plan menu, select TMS Domains

tms_define_priv

Qry TMS Domains

From the Plan menu, select Qry TMS Domains

rxc_any

Note:

You must also have TMS superuser privileges or the drop-down list to select a dictionary in the TMS Domain Elements window will be empty; see "Defining a New User" for information on granting superuser privileges.

Managing the TMS/Oracle Clinical Workflow

This section includes:

You can choose to review discrepancies/omissions first in either Oracle Clinical or TMS.

Regardless of whether you set First Review to Oracle Clinical or TMS, during Batch Validation all Oracle Clinical question responses collected since the last Batch Validation and marked for processing by TMS (see "Defining a Parent Question") are sent to TMS and inserted into the TMS SOURCE_TERMS TABLE with all their associated key data. Batch validation triggers TMS Synchronization and Autoclassification.

During Autoclassification, TMS searches for an exact match to a dictionary term or an existing VTA linking the same Oracle Clinical response/TMS verbatim term to a dictionary term.

For each term that is automatically classified:

  • In TMS, the verbatim term is associated with a VTA linking it to a dictionary term.

  • During the next Batch Validation, TMS sends to Oracle Clinical all the derived data defined in the question set variables.

    Note:

    If TMS is unable to derive a related term in one of the requested dictionary levels, it creates a high-level omission within TMS and sends all the derived values possible back to Oracle Clinical. When the high-level omission is resolved in TMS, TMS sends the remaining derived value(s) to Oracle Clinical. See "Resolving High-Level Omissions".

For each term that cannot be automatically classified:

  • TMS creates an omission.

  • During the next Batch Validation, Oracle Clinical creates a discrepancy.

  • Manual intervention is required; the workflow depends on whether First Review is set to TMS or Oracle Clinical. (See "Setting First Review".)

Normally you will want to handle omissions in TMS, because there you can specify how to handle the same verbatim term automatically in the future. However, you may prefer to check the data in Oracle Clinical first to correct any errors and send the data back to TMS for Autoclassification after it has been corrected.

A description of the workflow for First Review in TMS and First Review in Oracle Clinical follows.

First Review in TMS

If a term cannot be automatically classified and First Review is set to TMS, Batch Validation creates the Oracle Clinical discrepancy of category type Missing_PT with a status of TMS IN PROGRESS, which cannot be changed within Oracle Clinical.

You must handle the omission in TMS. You have two options: Manual Classification and Applying an Action.

Manual Classification

To classify a term manually after it fails Autoclassification, you must do one of the following:

  • Create a new VTA to link the verbatim term to a dictionary term. I

  • Add a new company term to the dictionary and create a VTA linking the verbatim term to the new term.

After you have manually classified a verbatim term, the next Batch Validation:

  • Sends to Oracle Clinical all the derived data defined in the question set variables.

    Note:

    If TMS is unable to derive all the data requested, it creates a high-level omission within TMS and sends all the derived values possible back to Oracle Clinical. When the high-level omission is resolved in TMS, TMS sends the remaining derived value(s) to Oracle Clinical. See "Resolving High-Level Omissions".

  • Gives the discrepancy a review status of CLOSED and a resolution status of:

    • VTA CREATED if the omission was resolved in TMS by creating a new VTA.

    • DT CREATED if the omission was resolved by creating a new dictionary term.

Applying an Action

If you cannot classify a verbatim term because of a flaw in the term, you can assign an Action to the term to send a message back to Oracle Clinical requesting a modification to the verbatim term. For example, Oracle Clinical may send a question response/verbatim term to TMS that includes two terms, such as "headache and nausea." Because TMS does not support combined verbatim terms, you might want to apply an Action to this verbatim term with the text "please split this term." During the next TMS Synchronization, the system sends this message back to Oracle Clinical as a comment associated with the discrepancy for the question response.

When the you apply an Action to an omission, the next Batch Validation:

  • Changes the status of the discrepancy according to the status specified in the definition of the TMS Action. Normally this is INV REVIEW (Investigator Review) to indicate that the investigator must take the next step in resolving the discrepancy, but it could be any valid status.

  • Inserts a message in the discrepancy's Comment field requesting clarification or other modification of the verbatim term.

In Oracle Clinical, the person responsible for resolving the discrepancy must make the requested change, if appropriate, and change the discrepancy's review status to TMS EVALUATION. During the next Batch Validation, the updated term is sent back to TMS for Autoclassification and the discrepancy's status is changed to TMS IN PROGRESS.

See "Defining and Using Actions" for more information.

Sending a Discrepancy Message

You can send a message to Oracle Clinical regarding a single source term in the Classify VT Omissions window. A Discrepancy Message is not predefined; you enter text specifically for a particular source term. See "Applying a Discrepancy Message".

First Review in Oracle Clinical

If a term cannot be automatically classified and First Review is set to Oracle Clinical, Batch Validation creates Oracle Clinical TMS discrepancies with a status of UNREVIEWED. You can then review each discrepancy and correct any errors. After correction (or at any time), set the discrepancy status to TMS EVALUATION. The next Batch Validation will change its status to TMS IN PROGRESS and pass it to TMS for Autoclassification. Corrected terms may be successfully auto. If not, an omission is created and you must handle it in TMS (see "First Review in TMS").

Setting First Review

Two settings determine which system handles the First Review, both set in Oracle Clinical: the Review Before TMS? setting in the Question Sets window and the FIRST_REVIEW short value in the TMS_OPTION reference codelist. The interaction between the two settings is as follows:

  • If the reference codelist value is NO (so TMS manages omissions), the value set in the Question Set window is ignored.

  • If the reference codelist value is YES (so Oracle Clinical manages omissions), clearing the Review Before TMS? box overrides the database setting and directs omissions to TMS.

In other words, to have Oracle Clinical do the first review of omissions, you must set both the reference codelist value to YES and select Review Before TMS? in the Question Set window. All other setting combinations result in a first review by TMS.

Batch Validation in an Integrated OC/TMS Environment

This section includes:

OC and TMS Data Exchanged During Batch Validation

Oracle Clinical Batch Validation runs on a single study, usually on a regular schedule such as nightly.

When Oracle Clinical and TMS are integrated, the Batch Validation job finds data that is new or changed in each system since the last Batch Validation and sends the relevant data to the other system. During the same Batch Validation job, TMS Autoclassification and Synchronization run in TMS on new Oracle Clinical data, and derived information, omissions, and Actions associated with that same data are sent back to Oracle Clinical.

During Batch Validation:

  • Oracle Clinical sends new parent question responses, plus their key information, to TMS. If responses have been deleted in Oracle Clinical, the deletions are sent to TMS.

  • Oracle Clinical sends responses whose question set definition has been changed.

  • Oracle Clinical sends discrepancies newly given a status of TMS EVALUATION.

  • TMS sends the derived values specified in the parent question's question set to questions whose parent question response has been classified, reclassified, or declassified in TMS.

  • TMS sends derived values to questions corresponding to high-level TMS omissions that have been resolved in TMS.

  • In the Oracle Clinical Discrepancy Database, Batch Validation resolves any discrepancies associated with question responses/verbatim terms that have been manually in TMS.

  • In the Oracle Clinical Discrepancy Database, Batch Validation applies any Actions that have been assigned to omissions in TMS to the discrepancy associated with the original question response. The Action Text is displayed in Oracle Clinical as the Internal Comment for the discrepancy.

  • Batch validation creates Oracle Clinical discrepancies for any terms TMS was unable to classify automatically (omissions). If First Review is set to TMS, these discrepancies have a status of TMS IN PROGRESS; if First Review is set to Oracle Clinical, they have a status of UNREVIEWED.

Running Only the TMS Portion of Batch Validation

Running only the TMS portion of Batch Validation may be useful when you are recoding a large amount of data but do not want to run other components of Batch Validation (such as Oracle Clinical Procedures). For example, if you have upgraded your dictionary version and anticipate a large number of terms to be processed.

To run only the TMS portion of Batch Validation, open Oracle Clinical. From the Conduct menu, select Data Validation, then TMS Derivation.

Note:

The TMS Derivation job runs the TMS portion of Batch Validation once, not twice as in the full Batch Validation job.

Batch Validation Execution Order

Batch Validation runs TMS processing twice, before and after running all validation and derivation procedures defined in Oracle Clinical for the study.

See "Using a Derived Question as a Parent Question" for information on how to use this feature.

Batch validation includes the following processes in the following order, for a single study:

  1. Sends data from Oracle Clinical to TMS for processing, including Synchronization and Autoclassification. (See "Synchronization" and "Autoclassification" for more information.)

  2. Returns data from TMS to Oracle Clinical, creating and resolving TMS-related discrepancies in Oracle Clinical.

  3. Runs all Oracle Clinical validation procedures, creating and resolving discrepancies.

  4. Runs all Oracle Clinical derivation procedures, generating values for derived question responses.

  5. Sends a limited set of data—parent question values derived during the current Batch Validation (if any)—to TMS for processing.

  6. Returns data specified in the derived parent questions' question sets to Oracle Clinical.

See "OC and TMS Data Exchanged During Batch Validation" for an explanation of which data is exchanged.

Effect of TMS Errors on Batch Validation

You can control whether Batch Validation fails altogether or just displays a warning if it encounters a serious problem during TMS processing by setting a reference codelist value in Oracle Clinical; see "OCL_STATE".

If the long value is active and set to Warn for the short value TMS_FAIL_BV_ACT in the OCL_STATE local reference codelist in Oracle Clinical, then if Batch Validation encounters a serious error during its TMS processing, it will give a warning but it will not cause the entire Batch Validation job to fail. Serious errors include:

  • a SQL error

  • data corruption

  • serious setup issue

If the long value is inactive or set to anything other than Warn, Batch Validation will fail if it encounters a serious error during TMS processing.

If Batch Validation encounters a less serious error during TMS processing, it will issue a warning but not fail, regardless of the long value set for TMS_FAIL_BV_ACT. For example, less serious errors include:

  • No value set for the local reference codelist TMS_OPTIONS.

    Batch validation displays the following error message: "Reference codelist for First Review Flag not found."

  • The dictionary specified for a question set used in the study is not included in any TMS domain element for the study in Oracle Clinical.

    Batch validation displays the following error message: "No dict. for Question Set: question_set_name."

  • The domain specified in the study's TMS domain element is not part of a valid dictionary/domain combination (as defined in the TMS Define Domains window) for one of the following: the dictionary specified in the domain element, or the dictionary specified for a question set used in the study.

    Batch validation displays the following error message: "No Domain for Question Set: question_set_name."

Setting Up Data Collection in Oracle Clinical

This section includes:

To use TMS with Oracle Clinical, you must define two types of questions and associate them with DCM question groups:

  • A parent question to collect data (called source terms in TMS) at an Oracle Clinical patient visit

  • A derived question to receive each piece of information you want to retrieve from TMS

In addition, you must define one or more question sets. A question set is a reusable structure that:

  • Specifies the TMS dictionary against which to classify the parent question response (TMS verbatim term)

  • Includes variables that specify the information you want to retrieve from TMS

During definition of the parent question you:

  • Link the parent question to a question set

  • Link a derived question to each question set variable

The diagram in Figure 4-1 shows the definitional links between Oracle Clinical and TMS. In the Oracle Clinical Global Library, you define parent and derived questions and questions sets, which specify questions' relation to dictionary data, and link parent and derived questions. In Oracle Clinical studies, you include parent and derived questions in the study definition and link the study to TMS domain/dictionary combinations. In TMS, you define valid dictionary/TMS domain combinations.

Figure 4-1 Relations Between TMS and Oracle Clinical Defined Objects

Description of Figure 4-1 follows
Description of ''Figure 4-1 Relations Between TMS and Oracle Clinical Defined Objects''

Defining and Using Question Sets

A question set defines the TMS information to be sent to Oracle Clinical in relation to a question response collected in Oracle Clinical. A question set definition has two parts:

  • Defining a Question Set. General information about the question set: its name, description, and TMS dictionary against which question responses are to be classified.

  • Defining Question Set Variables. Variables that specify the dictionary level and data to be derived (such as term, ID, or code; see "Parameter Name 2" for a complete list of derivable data).

    Alternatively, question set variables can derive Informative Notes from TMS to Oracle Clinical derived questions.

When you define a parent question (a question whose response is to be to a TMS dictionary term) you assign a question set to the parent question. Then, in the Details section of the parent question definition, you assign a derived question to each question set variable. Thus, the question set is the link between the parent question that collects Oracle Clinical data at a patient visit and the derived questions that contain information from TMS related to the response/verbatim term's classification in TMS.

You can assign the same question set to many different parent questions to collect the same TMS information for each parent question.

Note:

Define the question set completely before assigning it to a parent question. You cannot make changes to the question set after it is assigned to a parent question.

Defining a Question Set

To define the question set:

  1. In Oracle Clinical, from the Glib menu, select Question Sets, then choose Question Sets.

  2. In the QS Name field, enter a unique name assigned to this question set. It can be up to 20 alphanumeric characters.

  3. In the Description field, enter a description for the question set of up to 60 alphanumeric characters.

  4. In the QS Type Code field, choose TMS Q SET from the list of values. The code entered in this field determines which of the Parameter 1…5 fields must be completed. None are required for TMS.

  5. In the TMS Dictionary field, from the list of values choose the TMS dictionary to be accessed by this question set. You can use only strong dictionaries.

  6. Leave the Parameter 1…5 fields blank. These fields are not used in this context.

  7. Set the Review before TMS? box. Leave deselected to handle the initial review of thesaurus omissions in TMS.

    To handle the initial review in Oracle Clinical you must select this option and also set the short value FIRST_REVIEW in the local reference codelist TMS_OPTIONS to Yes (see "Managing the TMS/Oracle Clinical Workflow").

  8. Proceed to Defining Question Set Variables to complete the question set.

Defining Question Set Variables

Question set variables link child questions to the parent question and specify the information to be sent to and retrieved from TMS.

When you define a parent question to collect a drug name or medical condition to be classified in TMS, you associate it with a question set. The system populates the parent question's Details window with the question set variables. You must associate each variable with a child question that either sends additional information to TMS or holds information derived from TMS.

You define question set variables in the lower part of the Question Sets window. Each row defines one variable.

  1. Under Question Set Questions, click in the first available row.

  2. Specify a Sequence Number for the variable. This number represents the display order you want to appear in parent question's Details window, relative to the other variables in the question set. Sequence numbers can be up to three digits.

  3. Enter any value you want, from 1 to 30 alphanumeric characters, in the Parameter Name field. This field must be completed and each Parameter Name must be unique within the Question Set, but is not used by the system.

  4. In the Display Prompt field, enter the text that you want to appear as the variable name in the Details window of the parent question. This field will be mapped to a derived question. Consider using a naming convention to make it easy to decide which question you should associate with which variable; for example, dictionary level_type of information. See the possible types of information at Step 8 below. Up to 15 alphanumeric characters.

    Note:

    The reportable levels of the dictionary specified for this question set are listed in the Parameter Name 1 list of values.

  5. Choose a Data Type of CHAR.

  6. Len. Enter a length for the question set variable. It must be long enough to handle the data that will be returned from TMS. The largest amount allowed is 200. This is the recommended size.

    Note:

    You set the display length for the Data Entry form in the Len field in the DCM Questions window.

  7. Question Type. Select one:

    • OUTPUT if the variable is for information derived from TMS, such as a Preferred Term or ATC. Questions defined for this purpose must be defined as derived.

    • INPUT if the variable is to send auxiliary information to TMS in a dictionary with nonunique terms in the coding level, such as WHO-Drug Format C. You can use questions to collect auxiliary information such as Country, Pharmaceutical Form, and Strength in order to classify terms to nonunique dictionary terms.

    • INDICATION if the variable is to send information to TMS about the indication for which a drug was taken. For example, WHO-Drug supports classifying different occurrences of the same source term to different ATC terms depending on the indication. See "Classifying Indication Omissions."

  8. Parameter Name 1. The list of values varies depending on the question type:

    • For INPUT question types, all auxiliary information sublevels defined for the dictionary are listed.

    • For INDICATION question types, there is no list of values. Leave blank.

    • For OUTPUT question types, the list of values includes all dictionary levels and Info Note. Select one dictionary level from which to derive the term related to the parent question term. Alternatively, use Informative Notes to send additional information from TMS to Oracle Clinical. See "Defining Informative Note Attributes" for information about Informative Notes.

      Note:

      Do not enter the name of a group level here. To derive information from a dictionary level that is contained in a group level, you must enter the sublevel here, not the group level.

      If you have a Primary Link required to a group level, but a particular term's Primary Link is to any of the sublevels in the group level, you must create a variable for each sublevel.

  9. Parameter Name 2. The information you enter here depends on whether you chose a dictionary level or Informative Note in the Parameter Name 1 field and applies only to OUTPUT question types.

    Dictionary Level. If you specify a dictionary level in the Parameter Name 1 field, TMS returns information about the parent term's related term in that level. In the Parameter Name 2 field you must specify the type of data you want to derive from TMS.

    For example, if the verbatim term "Headache" is classified to Preferred Term "Head Discomfort," whose related High Level Term is "Neurological Signs and Symptoms NEC," and you specify High Level Term for the dictionary level in Parameter Name 1 and Term Upper for Parameter Name 2; if the question response value was "Headache," TMS would return the value "NEUROLOGICAL SIGNS AND SYMPTOMS NEC" as the value for the derived question specified in the parent question Details window for this variable.

    The list of values displays the following derivable data:

    • CATEGORY. Optional field used to by some dictionaries to further categorize terms; MedDRA supplies Diagnose, Adverse Event, or Undefined as categories for its terms.

    • COMMENT_TEXT. User-defined comment entered by the term's creator about the term.

    • DICTIONARY VERSION. The version of the dictionary, as defined by an Informative Note (see "Defining Informative Note Attributes").

    • DICT_CONTENT_ALT_CODE. Optional, user-defined, indexed, unique ID for a term. Designed to provide a link to another thesaurus system.

    • DICT_CONTENT_CODE. Optional field designed to serve as the primary key within a dictionary. TMS does not require that the dict content code be unique.

    • DICT_CONTENT_ID. Unique ID across TMS for this term; the primary key in TMS.

    • TERM. A term as entered or loaded (uppercase, lowercase, or mixed case).

    • TERM_UPPER. A term, all uppercase.

    • VALUE_1…4. Optional. Data defined by the user for a dictionary level. See "Defining Level Details".

    Dictionary Informative Notes. If you entered "Dictionary Informative Notes" in the Parameter Name 1 field, in the Parameter Name 2 field the list of values displays all the derivable Informative Note Attributes defined in this installation.

    For example, you can derive an Informative Note of type URL containing a link to information about the dictionary term.

    See "Defining Informative Note Attributes" for information about Informative Notes. For information about the particular Informative Note Attributes that have been defined for this TMS installation, from the Definition menu, select Define Informative Notes Attributes in TMS.

  10. Info Note? The system populates this field depending on the setting of the Parameter Name 2.

  11. Save.

Defining Questions

This section includes:

Two types of questions are used by TMS: parent questions are used to collect responses at patient visits; and child questions, derived questions that receive the information specified by question set variables from TMS. Use the standard Oracle Clinical question definition process for both parent and child questions, with the TMS-specific settings below.

Parent questions can also be derived questions in special cases; see "Using a Derived Question as a Parent Question".

You cannot convert an active, non-TMS question set question for processing in TMS. You must define a new question with a question type of Question Set and the name of its question set as part of the definition. You may want to model your TMS parent questions on your standard Glib questions, changing their names using a convention such as suffix _TMS.

Note:

A particular derived or parent question can be used only once within a question group: a particular question cannot be used in more than one question set, and can be used only once in a single question set.

Defining a Parent Question

The parent question collects the verbatim term (clinical data, question response) during an Oracle Clinical visit.

To define a parent question and link it to a question set:

  1. In Oracle Clinical, from the Glib menu, select Questions, then choose Questions.

  2. Complete the definition fields as usual in Oracle Clinical (see Oracle Clinical Creating a Study in the Oracle Clinical documentation set), completing these fields as follows:

    • Question Type. You must set this field to QUESTION_SET. This value activates the Question Set Name field.

    • Question Data Type. You must set this field to CHAR.

    • Question Set Name. Enter the name of the question set to which you want to link this parent question.

    • Derived? Normally you should leave this box deselected. However, there are some cases where you may want a derived parent question; see "Using a Derived Question as a Parent Question".

    • Display Prompt. This text becomes the display prompt in the Data Entry form.

  3. Save.

    Note:

    You can either activate the question now by setting the status to A, or leave it provisional so you can change it if necessary. You must activate it and save your work before you can link the question to a question group and use it in a study.

  4. Click the Details button to associate derived questions with question set variables. You must define the derived questions before you can do this step. See "Defining a Child Question" and "Associating Child Questions with Question Set Variables" for instructions.

Defining a Child Question

Create a child derived question for each variable of the question set. Consider using a naming convention to make it easy to remember which question you should associate with which variable; for example, dictionary level_type of information.

To define a child derived question:

  1. In the Oracle Clinical Glib menu, select Questions, then choose Questions.

  2. Complete the definition fields as usual in Oracle Clinical (see Oracle Clinical Creating a Study in the Oracle Clinical documentation set), completing these fields as follows:

    • Question Type. Set this field to THES VALIDATED.

    • Data Type. Set this field to CHAR.

    • Len (length) Enter a length at least as long as the question set variable it is being associated with (see below); the maximum setting, 200 characters, is recommended.

    • Derived. Select this box.

    • Default Prompt. Enter text to become the label for the derived question in the Data Entry form.

  3. Save.

    Note:

    You can either activate the question now by setting the status to A, or leave it provisional so you can change it if necessary. You can associate a provisional derived question with a parent question, but you must activate it and save your work before you can link the question to a question group and use it in a study.

Using a Derived Question as a Parent Question

Batch Validation can run its TMS process twice, once before and once after deriving question responses with Oracle Clinical derivation procedures (see "Batch Validation Execution Order"), and allows parent questions to be defined as derived, making it possible to do either of the following during a single Batch Validation job:

  • Derive a value to an Oracle Clinical question in TMS, run an Oracle Clinical derivation procedure to take that value and use it to populate the value of a (derived) parent question, and send the derived parent question value to TMS to derive additional Oracle Clinical question set question values.

  • Run an Oracle Clinical derivation procedure to populate the value of a (derived) parent question as necessary, and send the derived parent question value to TMS to derive additional Oracle Clinical question set question values.

Notes:

Oracle supports only the amount of derivation that can be accomplished within a single Batch Validation. Oracle does not support using an Oracle Clinical derivation procedure to populate the value of another derived parent question with the value of the original derived parent question.

Also, Batch Validation runs the TMS portion twice only if a derived parent question exists and requires processing.

Examples

Deriving a parent question may be useful in the following situations:

Deriving Data from Two Dictionaries for One Verbatim Term To classify a single verbatim term to two different dictionaries, and derive information from both dictionaries into Oracle Clinical, you can do so by defining two question sets, as follows:

  • The first question set references the first dictionary and includes a (non-derived) parent question to collect a response during data entry and derived child questions to receive TMS values from the first dictionary as specified by the question set variables (a standard Oracle Clinical TMS question set).

  • The second question set references the second dictionary and includes a parent question defined as a derived question and derived child questions to receive TMS values from the second dictionary as specified by the question set variables.

To populate the value of the derived parent question, you must write a derivation procedure in Oracle Clinical that propagates the value collected for the first parent question to the second (derived) parent question.

During Batch Validation, the system first derives values from TMS (from the first dictionary) for the first set of derived questions, then processes the derivation procedure that populates the second parent question value, and finally derives values from TMS (from the second dictionary) for the second set of derived questions.

Classifying a Term Substituted for the Original Question Response If many of the originally collected question responses are inconsistent with current terminology—for example, in a historic study or a study conducted by a company your company has acquired—you can leave the original data and thesaurus derivations, if any, intact but add current information by doing the following:

  1. Define a new question for each original question whose responses may be outdated.

  2. Examine each response to the original question and manually enter an appropriate value in current terminology for each corresponding new question.

  3. Define a new derived parent question also corresponding to each original question whose responses may be outdated. Associate the parent question with a question set and child derived questions to define and receive the related information you want to derive from TMS.

  4. Write a derivation procedure that compares the values of the original question and the new non-derived question, and populates the new derived parent question with the value of the new non-derived question if it has a value; otherwise with the original response.

  5. Run Batch Validation. TMS processes the value of the new derived parent question and returns the data specified in its question set.

Classifying Previously Unclassified Terms Add derived parent terms to legacy studies to derive TMS information for question responses that previously had no derived thesaurus information.

  1. Define a new derived parent question for each original question for which you want to derive thesaurus values. Associate the parent question with a question set and child questions to define and receive the related information you want to derive from TMS.

  2. Write a derivation procedure to populate the value of the new derived parent question with the original question's value.

  3. Run Batch Validation. Oracle Clinical runs the derivation procedure to populate the value of the new derived parent question, and TMS returns the data specified in the question set.

Associating Child Questions with Question Set Variables

After you have created a question set, a parent question to collect data, and all the child questions you need for the parent question, you must assign one child question to each variable of the question set associated with the parent question. If it is unclear what information should be associated with each variable, look up the question set definition from the Glib menu, by selecting Question Sets, and then Question Sets.

  1. In Oracle Clinical, from the Glib menu select Questions, then choose Questions.

  2. Execute a query for the parent question.

  3. Highlight the parent question name. This activates the Details button.

  4. Press the Details button. The Details window displays the prompts for the variables of the question set linked to this parent question (see "Defining and Using Question Sets").

  5. In the row for each variable, use the LOV to enter the name of the question you created to collect it.

  6. Save.

Associating Questions with Question Groups and DCMs

This section includes these special topics:

Before you can use parent or derived questions in a study you must associate them with a question group, DCM, DCI, and study as usual in Oracle Clinical (see the Oracle Clinical Creating a Study manual).

You do not have to use all the derived questions associated with a parent question in the Global Library. If you choose not to derive all the information defined in the question set, in the DCM question group you can simply not include the derived question mapped to the variable you do not need.

However, the parent question and all its derived questions you do need must be in the same question group.

All questions are visible in the data entry form, but only the parent question is enterable. When values are derived for the derived questions during Batch Validation, they are displayed in the data entry form. You can reference their values as you can any other question response values, in Oracle Clinical data extract and validation procedures.

You can associate the same question set with multiple parent questions in the same DCM.

Planning Question Groups and DCMs for RDC Special Listings

If you are using Oracle Remote Data Capture (RDC) Release 4.5.3.10 or above, you can use Special Listings to display concomitant medications and adverse events by patient. (If you are using TMS to code any other type of data, you can display Special Listings for it too.)

If RDC detects that any question in a DCM is a mapped to a TMS dictionary (is a parent question) it displays an additional item in the drop-down list of actions a user can take in the Home and Casebooks pages. By default, this item's text is: Review TMS_dictionary_name/DCM_name. You can substitute other text (such as Adverse Events or ConMeds) for the dictionary name by defining a special type of Informative Note. This text appears on the Special Listings page as well; see "RDC Action Informative Notes".

When a user selects a patient and selects a dictionary/DCM combination, the Special Listings page displays the patient's responses to all questions that are mapped to that dictionary in that DCM, in every visit and CRF where the DCM has been collected. In addition, the Auxiliary Information field displays the question name and the patient's response for every other question in the question group that is defined as Displayed and not as Derived.

In Figure 4-2, "RDC Special Listings Page" the response to the parent question is displayed in the Verbatim Term column. In the Auxiliary Information column, the system displays all other nonderived, displayed questions in the same question group as the parent question; in this case, Start Date, End Date, and SAE (Yes/No).

To optimize Special Listings behavior, plan Question Groups and DCMs as follows:

  • Question Groups. Include any questions related to the parent question that you would like to have displayed with it in RDC Special Listings, and do not include any questions you do not want displayed.

  • DCMs. To enable viewing all adverse event or all concomitant medication data for a patient at the same time, use the same DCM to collect adverse event or conmed data in any DCI/CRF where you need to collect it.

Figure 4-2 RDC Special Listings Page

Description of Figure 4-2 follows
Description of ''Figure 4-2 RDC Special Listings Page''

Adding Derived Questions to an Ongoing Study

If you initially do not include all the derived questions associated with a parent question and then decide midway through a study that you do want to derive that information, do the following:

  1. Add the derived question to the DCM in the DCM's Question Group Questions window.

  2. In Oracle Clinical, from the Plan menu, select TMS Domains. The Maintain Domain Elements window opens.

  3. Select the project to which the DCM's study belongs, and click Studies. The Studies window opens.

  4. Select the study to which the DCM belongs.

  5. Click Domain Elements. The Domain Elements window opens.

  6. Select the dictionary referenced by the parent question's question set.

  7. Click Force Rederivation. During the next Batch Validation run, all the parent questions associated with the study will be reprocessed and the associated derived questions repopulated or, in the case of the new question, populated for the first time.

Linking an Oracle Clinical Study to TMS

This section includes:

In TMS, you access dictionaries through a domain. Many domains can have access to the same dictionary. Each domain can have a different combination of dictionaries, different classifications, different company terms, and different rules; see "Creating Domains and Assigning Dictionaries to Domains". You can specify a virtual dictionary—a dictionary at a specified point in time—for a domain; see "Virtual Dictionaries."

In Oracle Clinical, you must define a TMS Domain Element. A TMS domain element specifies a TMS dictionary/domain combination and links that combination to an Oracle Clinical project or study. You must define a domain element for each dictionary/TMS domain combination used by a particular study or project.

If all studies within a project use the same TMS domain for a particular dictionary, you can assign a domain element to the whole project. If a project's studies use different TMS domains for a particular dictionary, you must assign a domain element to each study separately.

You can assign a domain element for one dictionary to the project, and domain elements for other dictionaries to the project's studies individually.

You can link a single study to more than one TMS domain and/or more than one TMS dictionary. For example, the following is a valid configuration:

  • Study A—Domain A—Dictionary A

  • Study A—Domain A—Dictionary B

  • Study A—Domain B—Dictionary C

In addition, you can change the rendition of a particular TMS dictionary you are using for a study. For example, if you are coding against a MedDRA base dictionary, you can switch to any virtual dictionary that uses the same base dictionary. Using a virtual dictionary for coding enables you to continue using the same terms and relations even as the base dictionary in your installation upon which it is based is modified or updated.

Translation Derivation

If you have set up two versions of the same dictionary, each using a different language, you can derive a dictionary term from one and the corresponding translated term (with the same dictionary code) from the other dictionary. The dictionaries you use must both be active, and have exactly the same structure, including the same level short names.

To do this, you define TMS domain elements that reference two domain/dictionary combinations: one for each language. In the domain element definition, you must call one dictionary the "Global Language" dictionary and the other the "Local Language" dictionary. Your choice for Global Language Dictionary must match the dictionary specified in question sets used in the study or project.

If you are not setting up translation derivation, enter a Global dictionary and domain only. Leave the Local dictionary and domain information blank.

Rules

The dictionaries you choose must satisfy these criteria:

  • Before you establish translation derivation for a TMS domain element, you must link the dictionaries you plan to use. See "Defining a Translation Derivation Link".

  • You can choose two base dictionaries or two virtual dictionaries in a TMS domain element, but not one of each.

  • You can choose either the global or local dictionary as the coding dictionary. TMS will derive the translation values from the non-coding dictionary, and rederive these values if they change.

Linking a Project with a TMS Dictionary and Domain

To link a project with a Global Language TMS dictionary and domain, and if necessary, a Local Language TMS dictionary and domain:

  1. In Oracle Clinical, from the Plan menu, select TMS Domains.

  2. Highlight the project code you want.

  3. Click the TMS Domain Elements button.

  4. Under the Global heading:

    • Select the short name of the Global Language TMS dictionary from the list of values.

    • Select the name of the Global Language TMS domain from the list of values.

  5. Save.

If you need to use more than one dictionary or TMS domain in this project, define additional domain elements on the following lines.

Note:

You can delete a domain element for a project only if there are no classifications or omissions associated with it.

Linking a Study to a TMS Dictionary and Domain

To link a study with a Global Language TMS dictionary and domain, and if necessary, a Local Language TMS dictionary and domain:

  1. In Oracle Clinical, from the Plan menu, select TMS Domains.

  2. Highlight the project containing the study you want.

  3. Click the Studies button.

  4. Highlight the study you want and click the TMS Domain Elements button.

  5. Under the Global heading:

    • Select the short name of the Global Language TMS dictionary from the list of values.

    • Select the name of the Global Language TMS domain from the list of values.

  6. If you are not setting up translation derivation for this study at this site, skip this step.

    Under the Local heading:

    • Select the short name of the Local Language TMS dictionary from the list of values, which includes only dictionaries that have Translation Derivation Links to your selected Global Language Dictionary.

    • Select the short name of the Local Language TMS domain from the list of values.

  7. To use the Global Language domain/dictionary combination as the coding dictionary for this study at this site, or if you are not setting up translation derivation, leave the Coding Dictionary? box selected. If you prefer to use the Local dictionary/domain combination as the coding dictionary, clear this box.

  8. Save.

If you need to use more than one dictionary or TMS domain in this study, define additional domain elements on the following lines.

You can also remove a TMS domain element from a study by deleting its row from the TMS Domain Elements for Studies window. When you remove its domain element, the study inherits the domain element for the same dictionary assigned to its project.

Note:

You can delete a domain element for a study only if there are no classifications or omissions associated with it.

Force Rederivation The Force Rederivation button invokes a job that tags all records (parent question responses) in the study associated with the selected dictionary for rederivation during the next Batch Validation job. Normally the batch validation job processes only records that are new or changed. Use the Force Rederivation job when you have made structural changes related to TMS in an ongoing study, including:

Using a New Version of a Dictionary for an Ongoing Study

After you link a project or study to an external dictionary, the dictionary vendor may issue a new version of the dictionary; see Chapter 8, "Upgrading to a New Dictionary Version" for information on TMS upgrade features.

Upgrading to a New Dictionary Version with the Same Structure

If the new dictionary version does not involve any changes to the dictionary's structure, you do not need to make any changes to your project or study definitions in Oracle Clinical.

Upgrading to a New Dictionary Version with a New Structure

If the new version does include changes to the dictionary structure-such as adding or removing a level, changing a level's name, or changing the relations between the levels-and you want to use the new version in an ongoing study, you must redefine the new dictionary version as if it were a different dictionary (see Chapter 6, "Defining and Loading Dictionaries"), relink your project or study, and redefine the questions and question sets used.

After you complete these steps, the Autoclassification process uses the new dictionary when trying to classify verbatim terms.

  1. Before you begin the dictionary upgrade for a study, ensure the following:

    1. Batch Validation has been executed and no new data is being entered into the study.

    2. All open "TMS IN PROGRESS" discrepancies are closed.

  2. For each question set used in each study, define a new question set referencing the dictionary version with the new structure.

  3. For each parent and derived question used in each study, create a new question. Add a question set referencing the new dictionary version to each parent question and associate new derived questions with the question set variables.

  4. Create a new TMS Domain Element with the new dictionary version.

  5. Add each new question to the same study question group(s) as the question it is replacing.

  6. For the old questions, deselect Collect in Subset. For new questions, select Collect in Study and Collect in Subset. If you want the question to be displayed in data entry screens, select Displayed as well.

  7. Edit the DCM layout and move the layout to production.

  8. Query existing responses from the OLD TMS parent question and spool a Batch Data Load (BDL) file which references the NEW parent question. For information on how to spool a BDL file, see Doc ID 2607190.1 on My Oracle Support.

    Once the BDL file is loaded, the new TMS Parent question is populated with the old value.

  9. From the TMS Domain Elements window, select the study, navigate to the TMS Domain Elements for Study window, and click Force Rederivation.

  10. Run Batch Validation for the study.

Accessing Oracle Clinical Data in TMS

Oracle Clinical sends information to TMS about the origin of each verbatim term occurrence. This information is stored in the TMS database, allowing you to query on Oracle Clinical-specific information within TMS. This external system information is available in the following TMS windows:

  • Classify VT Omissions

  • Approve VTAs

  • Approve Action Assignments

  • Browse VT Classification Data

  • High-Level Reclassification

  • Reclassify Verbatim Terms

The information includes the following database columns: Project, Study, DCM, Document Number, Visit, Patient, Discrepancy ID, and Investigator. In addition, you can choose to make details available for any of the above columns. This requires building an Oracle Clinical view and granting TMS users access privileges to the view. See "Define Column Details" for more information.

Setting Integration Reference Codelist Values

You must set values in four reference codelists in Oracle Clinical that determine aspects of the TMS-Oracle Clinical interaction:

OCL_OPTIONS_TYPE_CODE

The OCL_OPTIONS_TYPE_CODE installation reference codelist contains entries for optional subsystems that may be available to Oracle Clinical. To use TMS with Oracle Clinical, the short value TMS_INSTALLED must be set to Y. This value is set by a script during installation.

TMS_OPTIONS

This local reference codelist contains TMS-specific options. Currently the only option defined is FIRST_REVIEW. If the Long Value for this option is set to Y, and the Review Before TMS setting is also set to Y in the question set, then the First Review for a thesaurus omission happens in the Oracle Clinical Discrepancy Management System, rather than in TMS. For more information on the interaction between the Oracle Clinical Discrepancy Management System and TMS, see "Setting First Review".

DISCREPANCY REV STATUS CODE

This installation reference codelist provides the codes used by the Oracle Clinical Discrepancy Management System. Three are used in processing TMS omissions:

  • TMS EVALUATION

  • UNREVIEWED

  • TMS IN PROGRESS

UNREVIEWED is active by default, but you must activate the two TMS-specific values before you begin using TMS.

For more information on the interaction between the Oracle Clinical Discrepancy Management System and TMS, see "Managing the TMS/Oracle Clinical Workflow".

OCL_STATE

This local reference codelist includes one TMS-related short value: TMS_FAIL_BV_ACT. If it is active and its Long Value is set to Warn, then if Batch Validation encounters a serious error during its TMS processing, it will give a warning but will not cause the entire Batch Validation job to fail.

If the Long Value is inactive or set to anything other than Warn, Batch Validation will fail if it encounters a serious error during TMS processing.

If Batch Validation encounters a less serious error during TMS processing, it will issue a warning but not fail, regardless of the long value set for TMS_FAIL_BV_ACT.

See "Effect of TMS Errors on Batch Validation" for more information.