CRF Version Migration is a new feature of OpenClinica available starting from OpenClinica 3.1.3. CRF Version Migration supports the ability to migrate data entered for a particular version of CRF for the subject to a different available version of the CRF. No data entered for the subject will be deleted from the database as a result of CRF version migration.

The CRF Migration feature can 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 ( Reassign CRF to a New Version )  icon for the CRF.  CRF Version Migration Image 1


Once OpenClinica user clicks the icon he will be redirected to Reassign CRF to a New Version page (see below) that allows user to select desired CRF version that he would like to migrate the eventCRF to. The page also gives access to different screens that provide information about CRF definition, available versions for the CRF, CRF metadata and so on. Cancel button redirects user to ViewStudySubject page regardless of from what page he came from.CRF Version Migration Image 2

After the target version is selected, user clicks Continue button. If no version was selected user will be redirected back with error message (Please select CRF Version.) posted in ‘Alerts and Messages’ panel on left side menu.

Next page Confirm CRF Version Change allows user to verify his choice. It presents data information transfer as a multi-column map where data available for the current CRF version are listed in the first three columns of the view (item name, item OID, item data). The second set of columns gives information what data will be transferred to the selected CRF version. Based on this view user can easily determine what data will be transferred to the new CRF version.

CRF Version Migration Image 3

Please find several examples on how data will be transfered below:

1)       Case A:

  • Pre-Conditions: CRF Version A has an item called meditem2, CRF Version B does not have the item. Both versions have an item called item_1. EventCRF have been migrated from Version A to Version B.
  • Outcome: data for item item_1 are transferred, data for item meditem2 have not been transferred meaning that when eventCRF record will be open user will not see meditem2, because it does not belong to the current CRF version, and data for this item will not be pulled by extract (see below for extract rules). However, data for the item is not removed or altered on database level, so once eventCRF will be migrated back to the original version of CRF data for the item will be shown;

2)       Case B:

  • Pre-Conditions: 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 on data entry. EventCRF have been migrated from Version A to Version B.
  • Outcome: data for item_1 is transferred, however, because active version of CRF does not have option Z, as a result a user wont see selection and the field appears as if no data has been entered. For single select response types  (single-select and radio) 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, item_1 has a checkbox response-type, after CRF version migration to CRF Version B user wont see that field has a value Z, so he selects option Y. User see only option Y selected, however, the field has both Y and Z options stored in database.

3)       Case C:

  • Pre-Conditions: Both CRF Version A and B have a repeating group Group1. Parameter GROUP_REPEAT_MAX for  Group1, Version A is bigger than the same parameter for Group1, Version B, maximum allowed number of rows have been entered for Group1. EventCRF have been migrated from Version A to Version B.
  • Outcome: After migration user will see all rows entered for the eventCRF despite the fact that Version B allows less records to be entered, but no new row can be added.


1) Audit Log: CRF version migration event is reflected in audit log with information about original CRF version and target CRF version.

2) Data Validations will be run based on the rules associated with active (new) CRF version after CRF version migration.

3) E-signature status. If study subject or event CRF has been e-signed before CRF version migration the migration process will trigger removal of electronic signature. The rules are:

  • If event CRF is signed, but subject is unsigned: CRF that was migrated will be unsigned.
  • If subject is signed: subject and event CRF that was migrated both will be unsigned.

Both objects will be returned to the state they have been before electronic signature.

4) SDV status of the subject will be reset to the need source data verification after CRF version migration.

5) Extracts: Values for items not present in active CRF version definition will not show up in the extracts in OpenClinica 3.1.3.  For example, data have been entered in CRF Version A for an item ITEM_A, than eventCRF have been migrated to Version B, which does not have ITEM_A. Value for ITEM_A will not be present in extract.

6) RESPONSE SETS: 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)

7) Reassign CRF Version icon will be shown even if CRF has only one version.