Summary

This article covers defining the coding of terms and defining the information displayed in the Coding Manager.

Table of Contents


The Codes worksheet defines the coding of terms within the application. This includes the specification of terms to be coded, whether they are auto coded, what levels of the dictionary to export as well as what dictionaries to be searched. In addition to defining the coding of terms, the Codes worksheet also defines the information displayed in the Coding Manager.

questionTypeId

This is where to enter the questionTypeId from the Question Types worksheet to which a code will be assigned. This defines the question to be evaluated for coding. i.e., aeTerm, medication.

autoCode

This is where to enter ‘yes’ to have the Coding Manager attempt to map the variable. Enter ‘no’ when the user should manually map all terms to the appropriate dictionary term. However, if the client is utilizing the coding features, it is almost always set to ‘yes’.

exportLevels

This is where to enter the coding levels the user wishes to export with the coded variable; i.e., for all levels of MedDRA to be exported, list LLT, PT, HLT, HLGT, SOC. This varies depending upon the dictionary. Both the term and description are exported. Both MedDRA and WHO have five levels. However, it can be prompted for all or only certain levels.

  • MedDRA the level options are: LLT,PT,HLT,HLGT,SOC
  • WHO C and C3 Format the level options are: ATC1,ATC2,ATC3,ATC4,MP
  • WHO B2 and B3 Format the levels options are: ATC1,ATC2,ATC3,ATC4,DD

You can also include additional information in the exports by changing the export level definition. For example, if you wanted to include the PREFERRED NAME and INGREDIENTS, simply modify to the following:

  • WHO C and C3 Format the level options are: ATC1,ATC2,ATC3,ATC4,MP(PREFERRED_NAME|INGREDIENTS)
Note: If you intend to use Ingredients in the text export, you need to change the delimiter for the text export to be something other than comma as the ingredients are separated by commas. 


auxiliaryQuestions

These are additional questions appearing in the Coding Manager to provide further information to the Coder role. These exist more for medications (indications) than for AEs (body systems). Auxiliary Questions help the Coder role decide which codes should be used when they are trying to code the term.

auxiliaryTerms

In some cases, the term entered in a question may match multiple codes in a dictionary. The term itself is not sufficient to help select the appropriate code from the list. The feature of auto-coding using auxiliary terms allows a question to be auto-coded with the help of additional terms in other questions. For example, assume a form has three questions: Med, Indication, and AE. The auxiliaryTerms attribute for Med question is defined as:

auxiliaryTerms = “Indication + ‘ ‘ + AE, Indication, AE”.

The auto-code function will search for a code using the following composite terms one by one and stops when an exact match is found. If no match is found then an attempt will be made to simply code the Med question itself. Searching for a composite term will be repeated for each specified dictionary and synonym table.

  • Med + ‘ ‘ + Indication + ‘ ‘ + AE
  • Med + ‘ ‘ + Indication
  • Med + ‘ ‘ + AE

The auxiliaryTerms attribute defines the search order of the composite terms. The value of the attribute can be blank (by default), or a comma separated list of expressions, where each expression is composed of single or multiple question aliases. These exist more for medications (indications) than for AEs (body systems).

useAppSynTable

The attribute useAppSynTable defines whether or not dynamic synonyms and dynamic synonym tables are allowed to be created in this trial. The value of the attribute can be blank by default (equivalent to “no” in its function), “no”, or “yes”. The permissions to use the Synonym table must also be given in the Roles tab to use this feature.

Reference – Key Name

This links the question to be coded to the appropriate dictionary. The keyName of the requested dictionary for the specified questionTypeId should be entered here. This also allows the use of a synonym dictionary to aid in comprehensive coding capabilities. Up to one dictionary and/or one custom synonym table can be searched for a single term; list the corresponding keyNames in order of preference. When using a custom synonym table, it is recommended that the dynamic synonym functionality described above not be used.

Example keyName: Fountayn’s keyName for the WHODrug dictionary released September 2005 is ‘WHO200509′.

Fountayn has a full list of available keynames for dictionaries that are currently installed.

Warning: Do not change dictionary formats between the old and new versions, the two version are incompatible.

Start Level

This is where to enter the lowest level of code the user wants to display in the Coding Manager; i.e., LLT (MedDRA), MP or DD (WHO).

End Level

This is where to enter the highest level of code (the level at which to end coding – determining when the item is completely coded) the user wants to display in the Coding Manager; i.e., SOC (MedDRA), ATC1 (WHO).

Primary Path

For MedDRA dictionaries, the Primary Path can be set to the following values:

ValueResult
yesAutomatically codes terms to the predetermined SOC path (as specified by MedDRA)
noWill require manual coding for partially coded terms
onlyWill display only the primary SOC when viewing search code page

Additional Fields on Search Screen

To view additional fields from the dictionaries on the Search Screen use the property [DictionaryKeyName][Level], in the App Properties tab of the DataArchitect, with a comma-separated list of properties from the dictionary.



Need more help?

Please visit the Fountayn Contact Information page.