1. Help Center
  2. Medication and Event Coding

Medical Coding Configuration

How to Setup a Study for Coding Events and Drug Terms

This article covers how to configure a study for medical coding and manage coding projects. Check out this other article for help on using the coding tool on an existing study.

Configuring Forms for Coding

For studies collecting data in TrialKit EDC where data needs to be coded with MedDRA or WHODrug dictionaries, it is required that the forms first be mapped to the corresponding dictionary.

If TrialKit Coder is being used to code data coming from outside of TrialKit, skip to the next section. Mapping forms is not necessary.

If Events or Drug terms are being collected in a study, they must be collected using Text fields.

For example, an Adverse Event form will contain a text field for the user to type in the Event name, and another text field for the system to store the medical code.

The text fields also need to be mapped within the form's special type properties.

Here's an example of a Medication form collecting a Drug name that needs to be coded. At minimum, for both events and drugs, there needs to be a field collecting a Term and another field for the Code.

It's also possible to map a field within a normalized table, for instances where there are multiple terms being collected on a form, such as a Medical History form.

A Single form cannot collect multiple terms outside of a normalized table. In those instances, the form needs to be made into a Log Form for the users to enter terms into separate records.

Here are some other common examples:

  • Adverse Event form will contain one MedDRA term and one MedDRA code

  • The medical History form will contain one MedDRA term and one MedDRA code.

  • Concomitant Medications form (similar to the image above) will contain one WHO Drug term (text field), one WHO Drug code (text field), one WHO Drug Description/Indication (memo field), and one WHO Drug Route (text or choice field). 

Do not build a hide condition on the code field - as hiding inherently clears data. Instead, use role-based blinding if you don't want the user to see the code within the CRF.

Optional Suggestions:

  • The code field can be conditionally disabled to prevent the data entry person from accessing it.
  • Another field property, a special type, called "medcode field" can be mapped to any text or dropdown/choice field on the form. This will allow the Coder to pull that data into the medical coding tool for ease of reference by the person performing the coding. For example, the coder may want to know the dose of a medication or the severity of an event to aid in how an item is coded.


Importing data - Standalone Coding Only

TrialKit Coder can be used as a standalone coding tool where data is imported from an external source for the sole purpose of coding the data and managing changes to those codes over time.

Prerequisite: User has Access to Medical Coding and Add New Configuration

Open TrialKit Coder and locate the option to import data. If the study data is being collected in TrialKit EDC, this option will not be available.

Upload a CSV formatted file containing the minimum headers (in any order) shown in the tables below.

Any other column names and data can be included as needed. Avoid duplicate column names.

 

MedDRA coding:

Column Name

Description

PatientIdentity

Used to Identify an individual Patient

Date

Used to Create a Tx Starting Date and Visit Date

AETERM

MedDRA Search Term (MedDRA Only)

RecKey

Unique Record Key, used to insert new records or update existing records

 

WHODrug Coding:

Column Name

Description

PatientIdentity

Used to Identify an individual Patient ID

Date

Used to Create a Tx Starting Date and Visit Date

CMINDC

WHO Indication Term 

CMROUTE

WHO Route Term 

CMTRT

WHO Search Term 

RecKey

Unique Record Key, used to insert new records or update existing records

RecKey is a unique identifier for each record. This must be unique to prevent any overwriting of records. This also makes it possible to update the data later on. By adding new lines to a file, or updating existing items from a previous import, the RecKey column is how the system knows to update a record or create a new one.

 

Once the file is uploaded, a coding project can be created, where the file name that was uploaded will be the name of the data source selected.

The file name will be very important moving forward because it will need to be used for updating the data.

Updating the Data in an Existing Coding Project

If a standalone coding project needs to have records updated and/or added, this is a simple step of re-uploading the same file name.

The system uses the record key column (described in the table above) to determine if it should update an existing record or add a new one.

Existing coding will not be affected unless the verbatim term changes. In that case, the coding details no longer apply and are cleared.

Creating Coding Projects

A required one-time step in coding a given dataset/form in a study is to create a coding "project" for that data. For example, an individual study might have three different coding projects - one for the adverse events, one for concomitant medications, and one for medical history.

Prerequisites:

  • Study is licensed for medical coding
  • User has Access to Medical Coding and Add New Configuration

Open TrialKit Coder and locate the button to Add a new project.

If you belong to multiple studies, take note of the study name at the top of the screen to verify you are in the correct one. If needed, other studies can be accessed from the hamburger menu at the upper right corner of the screen.

 

Fill out the form that pops up with the details described below.

Configuration Name - Name the project. If doing standalone CSV importing (described below), be sure to first upload the file before doing this step. If using the mobile app, be sure the name of the configuration matches the name of the CSV file, without the file extension on the end. 

Medical Coding Type - Select which dictionary will be used for the dataset being coded. The options here depend on which dictionaries have been enabled. Contact your account representative with any questions about this.

Review Levels - Define which user roles need to perform review on coded items. This step is optional and can be left blank if workflow is not needed. Provide both the applicable role and a name for the level of review. Up to two review levels can be defined, but none are necessary.

Data Source - Choose a data source for the coding project. This will be either a form from TrialKit EDC or an imported data file name (for standalone coding)

 

NOTE: Once a coding project is created, it can be opened by any user who has been given access to the Coding tool for that study.

 

Providing Users With Access

To provide a user access to perform coding on a study, it might be necessary to set up a unique "Medical Coder" role that only has access to coding, but not other TrialKit functions. In any case, some role will need to be given access within the study role security as shown below. Additionally, the user(s) will need to be added to at least one site in the study.

Here is a suggested set of permissions granted to a Medical Coder:

 


Dictionary versions

Dictionary versions are set by TrialKit technical support based on licensing. New coding projects start by filling out this form which is used to document which versions the database will use.

If the version(s) need to be changed at any point, the same request form should be completed again by the project owner. This serves as documentation for CDS that the version is being altered.

Please use the dictionary organization's available tools to pre-assess what impact the new dictionary version will  have on your coded terms. TKCoder will not perform the comparison but does provide the means of exporting data prior to the change so you have a recorded file of how the data existed. 

What happens when the version is updated

After the request is routed and the version gets updated, there will be some impact on the coding project(s). These should be considered when up-versioning any dictionary.

  • The coded data within Coder will all get blanked out again - appearing on the screen as if they have never been coded.
  • The coding data exports will still contain the older coding information for each record individually until each one is coded on the new version.