CRF Version Migration was first introduced in OpenClinica 3.1.3 and supports the ability to migrate data entered for a particular version of CRF for a subject to a different available version of the CRF. This is done on a subject-by-subject, event-by-event basis. Starting with OpenClinia 3.12, there is also the option for Batch CRF Version Migration, which allows you to migrate from one version of a CRF to another for all Events and all Subjects in a Study. The subject-by-subject migration and batch migration steps are outlined below.
Regardless of which means of migration you use, no data entered for the subject is deleted from the database as a result of CRF version migration. However, data that had previously been entered may not display on eCRFs or in extracts if previous versions of a CRF had more items than the new CRF to which data was migrated. Details of various migration examples are provided below.
CRF Version Migration: Subject-by-Subject
The CRF Migration feature is accessed from View Study Subject and Enter Data for Study Event pages for users with appropriate privileges.
Conditions for event CRF Version Migration feature:
- Data Entry status: event CRF has been started (user started data entry or only opened CRF and exit it without any data saved);
- Study status: Available;
- User Role: Study Director or Data Manager;
- Subject Status: Subject should be active;
- Event Status: event should be active (not removed, locked or skipped);
- CRF Status: Active (not removed)
- CRF Version: only active (not removed) CRF versions will appear in drop down as possible migration targets;
- CRF version migration is only available if CRF Version used for data entry is an active CRF version.
If the above conditions are met for the event CRF the user will see the reassign ( ) icon for the CRF.
To migrate data for an Event for a Subject:
- Click the Reassign CRF to a New Version icon.
This opens the Reassign CRF to a New Version page.
- To cancel and return to the View Study Subject page, click Cancel.
- To migrate the Subject’s Event CRF to a new version:
- Review the list of available versions and select the version to which you want the data migrated.
- Click Continue.
The Confirm CRF Version Change page displays.
- Verify the migration details and click Submit.
- Scenario A:More items in original CRF than resulting CRF
- Before Migration:
- CRF Version A has an item named meditem2.
- CRF Version B does not have the ‘meditem2’ item.
- Both CRF versions have an item named item_1.
- The EventCRF has been migrated from Version A to Version B.
- After Migration:
- Data for item item_1 are migrated.
- Data for item meditem2 are not migrated.
- When the EventCRF record is viewed, the user will not see meditem2, because it does not belong to the current CRF version.
- Data for this item will not be included in extracts (see below for extract rules). However, data for the item is not removed or altered in the database, so if the EventCRF is migrated back to the original version of the CRF, the data for the item will be displayed in the EventCRF and in the extract.
- Scenario B:More Response Options in original CRF than in resulting CRF
- Before Migration:
- Both CRF Version A and B have an item called item_1.
- Version A has response options X, Y and Z.
- Version B has response options of X and Y only.
- User selected option Z during data entry in Version A.
- The EventCRF was then migrated from Version A to Version B.
- After Migration:
- The data for item_1 is migrated, however, because the active version of CRF does not have option Z, the user wont see the selection and the field appears as if no data has been entered.
- For single select response types (single-select and radio button), new data, if entered, will overwrite the existing value.
- For multi-select response-types (multi-select and checkbox), new choices will be added.
- For example, if item_1 has a checkbox response-type, after migrating to Version B, the user wont see that the field has a value of Z as an option and selects option Y. Though the user only sees option Y selected, the item has both Y and Z options stored in database.
- Scenario C:Group Repeat Max in original CRF is greater than the Group Repeat Max setting in the resulting CRF
- Before Migration
- Both CRF Version A and B have a repeating group Group1.
- The parameter for GROUP_REPEAT_MAX for Group1 in Version A is 5.
- The parameter for GROUP_REPEAT_MAX for Group1 in Version B is 3.
- Data was entered into Version A with 5 repeats in Group1.
- The EventCRF was migrated from Version A to Version B.
- After Migration:
- All 5 rows entered for the eventCRF display, despite the fact that Version B allows fewer rows to be entered.
- No new row can be added.
Only One CRF Version
The Reassign CRF Version icon will be shown even if CRF has only one version.
CRF version migration events are reflected in the audit log with information about the original CRF version and target CRF version.
Data validations are run based on the rules associated with active (new) CRF version after CRF version migration.
If the subject casebook or an EventCRF has been e-signed before CRF version migration, the migration process removes the electronic signature for the EventCRF that had been migrated.
The SDV status for migrated CRFs will be reset to need source data verification after CRF version migration.
Values for items not present in active CRF version definition do not show up in the extracts. For example, data is entered into CRF Version A for ITEM_X. Then that eventCRF is migrated to Version B, which does not have ITEM_X. The value for ITEM_X will not be present in extract for the migrated CRF.
Please note that OpenClinica 3.1.3 does not impose restrictions on the Versioning of response sets. If you assume that individual event CRF will have to be migrated from one CRF Version to another, response sets for the same item MUST have unique values across all CRF versions. For example, an item is a single-select and its RESPONSE_OPTIONS_TEXT defined as Absent, Mild, Moderate, Severe, Life-threatening while RESPONSE_VALUES_OR_CALCULATIONS defined as 1,2,3,4,5 in one version. You can to drop or add several values in another version of CRF, but you cannot redefine mapping by setting Absent to have value other than 1 (OpenClinica 3.1.3 and early does not check for consistency of mapping)
Batch CRF version migration was introduced in OpenClinica 3.12. This allows you to migrate from one version of a CRF to another for a group of subjects and/or events.
To perform Batch CRF Version Migration:
- From the menu bar, select Tasks > Monitor and Manage Data > CRFs.
The Manage Case Report Forms (CRFs) page displays.
- On the Manage CRFs page, for the CRF that you want to migrate, click the Batch CRF Version Migration icon:
The following screen displays (note that the screen name will vary based on the selected CRF):
- Select the current version of the form.
- Select the version to which you want to migrate the form data.
- Select migration options as follows:
- In the Site(s) selection box:
- To migrate the selected CRF for a specific site, select the site for which you want to migrate forms
- To migrate the selected CRF for multiple sites, hold down CTRL (CMD on Mac) and click the sites for which you want to migrate forms
- To migrate the selected CRF for subjects entered at the study level, select Study Level Subjects Only
- To migrate all study and site-level subjects, select -All-
- In the Event(s) selection box:
- To migrate the selected CRF for a specific event, select the event for which you want to migrate forms
- To migrate the selected CRF for multiple sites, hold down CTRL (CMD on Mac) and click the Events for which you want to migrate forms
- To migrate the selected CRF for all sites, select -All-
- Click Preview.
A count of the number of subjects and event CRFs displays. If both counts are 0, migration is not possible.
- If the number of records meets your expectations, to complete the migration, click Migrate.
You return to the Manage CRFs page and the following displays in the Alerts & Messages section:Batch CRF version migration is running. You will receive an email once the process is completeYou will receive an email notification indicating that the migration is complete. The email will contain a link to a report of the migration, which will provide a list of all migrated Subjects and Event CRFs.