Migrating Code Requests

For InForm Studies, you can ingest coding data and migrate it as Code Requests into CDMS for use with Vault Coder.

This functionality is available for the following dictionaries:

MedDRA: 19.1 - 25.0
WHODrug B3: March 2017 - March 2022

InForm Support: In the current release, Migration Vault only supports the migration of Code Requests from InForm.

Prerequisites

Configuration

Before you can migrate coding data, a CDMS user must complete the following configuration tasks:

Set up the coding configuration for the Form in Studio
Assign a Dictionary Version to the Form in Coder Tools
Assign a Synonym List to the Form in Coder Tools

Required Permissions

Users with the Migrator security profile can perform the actions described below by default. If your vault uses custom Security Profiles, your profile must grant the following permissions:

Preparing Coding Data for Migration

You will need to add additional columns to the form’s CSV file to capture coding information. This requires specific values based on the dictionary you’re using.

Required columns for MedDRA:

LLT: Include a column to list the LLT assigned to the verbatim for the form.
Dictionary Release: Include a column to list the Dictionary Release for the form.

Required columns for WHODrug:

Drug Code: Include a column to list the Drug Code assigned to the verbatim for the form.
ATC4: Include a column to list the ATC4 assigned to the verbatim for the form.
Dictionary Release: Include a column to list the Dictionary Release for the form.

Add Coding Information to the Form’s YAML File

To migrate Code Requests, you must add a new coding section aligned with the item-level map. This coding section requires additional parameters, based on the dictionary that you’re using.

MedDRA

The following parameters are required for MedDRA:

lltColumnName: Enter the name (column header) of the column in your form’s CSV where you list the LLT.
dictionaryReleaseColumnName: Enter the name (column header) of the column header in your form’s CSV where you list the Dictionary Release.

The YAML below is an example of an Adverse Events form set up for coding with MedDRA.

file: AdverseEvents.csv
headerfile: non-unscheduled-header.yaml
targets:
    - CASEBOOK
    - EVENT_GROUP
    - EVENT 
    - FORM
    - ITEM_GROUP
    - ITEM 
eventGroups:
    - map: { veevaDef: eg_LOGS } 
      events: 
          - map: { columnValue: AE, veevaDef: LogEvent } 
            forms:
                - map: { columnValue: AE, veevaDef: AdverseEvents } # Form - Adverse Events 
                  repeating: true
                  itemGroups:
                      - map: { veevaDef: igAdverseEvents_F1_S1 }
                        items: 
                            - map: { columnName: AETERM_AE3001_F1, veevaDef: AETERM_AdverseEvent_FT }
                              coding: 
                                  lltColumnName: AELLTCD_AE3001_F1
                                  dictionaryReleaseColumnName: DICT_DICTVER_AE3001_F1

WHODrug

The following parameters are required for WHODrug:

drugCodeColumnName: Enter the name (column header) of the column in your form’s CSV where you list the Drug Code.
atcColumnName: Enter the name (column header) of the column in your form’s CSV where you list the ATC Code. See details below.
dictionaryReleaseColumnName: Enter the name (column header) of the column in your form’s CSV where you list the Dictionary Release.

Coding with ATCs Setting Override: If you provide values for ATC Code, and your Study doesn’t have the Code with ATCs setting set to Yes, Vault will override this setting during ingestion and import the ATC Code values.

With the 22R3 release, we began supporting ATC levels 1 through 4 by replacing the YAML parameter from “atc4ColumnName” to “atcColumnName”. We are continuing to support “atc4ColumnName”, so if you use this parameter, Migration Vault will default to the ATC4 code and will not check other ATC levels for a match.

If you use “atcColumnName”, Vault searches for the combination of Drug Code and the ATC Code value provided against the ATC4 Code, then checks ATC3, ATC2, and lastly ATC1, until a single match is found. If a Drug Code is provided, but the Code Request doesn’t include a value for the ATC Code in the data file, Vault searches only for the Drug Code and only stores the code if there is a single match.

The YAML below is an example of a Status Visit form set up for coding with WHODrug.

file: StatusVisit1.csv
headerfile: non-unscheduled-header.yaml
targets:
    - CASEBOOK
    - EVENT_GROUP
    - EVENT 
    - FORM
    - ITEM_GROUP
    - ITEM 
eventGroups:
    - map: { veevaDef: eg_SCR } 
      events: 
          - map: { columnValue: V1, veevaDef: ev_V1 } 
            forms:
                - map: { columnValue: STAT_V1, veevaDef: StatusVisit1 } # Form - Subject Status: Visit 1 
                  repeating: true
                  itemGroups:
                      - map: { veevaDef: igStatusVisit1_F1_S1 }
                        items: 
                            - map: { columnName: STAT_V1_STATGUT_F1_C, veevaDef: STAT_StatusVisit1 }
                              coding: 
                                  drugCodeColumnName: DRUG_CODE_S1
                                  atcColumnName: ATC4_S1
                                  dictionaryReleaseColumnName: DICT_DICTVER_S1

How Vault Coder Creates Code Requests

After the migration load is completed, Vault Coder begins creating Code Requests for each provided verbatim in Forms that are in the Submitted status. Vault creates one Code Request per instance of the Form.

Based on the data provided in the load, Vault assigns different Coding Statuses:

Open: Assigned when there is no value provided for LLT or Drug Code
Coded: Assigned when there is a value provided for LLT or Drug Code
Noncurrent: Assigned when the Dictionary Release provided does not match the Dictionary Release currently assigned to the Form in Vault Coder

Coders will review Code Requests in the Open and Noncurrent statuses and manually apply codes.