Data can be reviewed using the Participant Matrix, Queries, or Source Data Verification screen.

Review and Manage Data from the Participant Matrix

The Participant Matrix

Typically, Data Managers and Monitors are responsible for reviewing data, but anyone with access to the Participant Matrix can view/review data as needed. Data Managers can also remove a participant and/or reassign a participant to a different site. The actions column presents the appropriate actions available, based on your user role.

The following displays the actions available to a Data Manager:

Remove a Participant

Data Managers have access to remove Participants.

Removing a Participant does not delete the Participant, but instead removes access to that Participant’s data. The data for that subject can still be viewed, but cannot be edited and will not be included in data extracts.

Participant Matrix with Remove Tool Tip for removing a participant

Remove Participant with Reason for Change

Once a Participant is removed from the study, the Remove icon changes to a Restore icon. To restore access to that Participant’s data, simply click the restore icon and the data is available again for editing and extracts.

Restore Participant on Matrix

Restore Participant with Reason for Change

When removing or restoring a participant, you will be required to enter a reason for change.

Reassign a Participant

Data Managers also have access to reassign a Participant to another site. This may be needed if a Participant moves to a different location but still wants to continue on the study.

Prior to reassigning, be sure that the original site has an extract of that Participant’s data. Then, to reassign a Participant, click the Reassign icon. Specify the new site and click Reassign Participant.

Reassign Participant from Matrix

The new site has immediate access to that Participant’s forms and all data previously collected for the Participant. The original site no longer has access to that Participant’s ongoing data.

View, Edit, Lock, Remove and Restore Events

Click an Event icon on the Participant Matrix to display a pop-up. Then, click the action you want to take.

When removing or restoring an event, you will be required to enter a reason for the change.

Note: When reviewing a form which had data entered prior to the event being removed, you will see the message The event this form is in has been removed” at the top of the form. 

Review Participant Data

To review data, click the View icon for the participant whose data you’d like to review.

To review data on a specific form, click the View icon for that form.

Filter Participant Details

As you review data, you can enter search criteria for the Common Events – for example, to show only AEs that are ongoing. You can also change the number of rows listed for any of the Common Events, and you can sort Common Events by clicking any of the column headings. When you customize anything related to what is displayed for Common Events, the Custom View On button displays at the top of the Participant Details screen. Custom View On also displays when collapsing or expanding sections (changing from their default), sorting and searching in the Visits section, and changing the default Showing record filter in the upper right corner (Active Records, All Records, Removed Records).

The Custom View is active for that participant throughout the time you are logged into OpenClinica. If you view a different Participant’s details, the view might not be customized, or it may be a different customization. In the example above, throughout the current session, any time you view participant 001, that same custom view is in effect, even if you leave the page and come back to the same participant.

To clear a custom view, click the X on the Custom View On button and all view customizations are removed for that participant, bringing you back to the default view. The Custom View could be as simple as collapsing the General Information section or searching for a specific form name, but it will persist on that participant until you either clear the custom view by clicking the X, manually change the custom view back to the default, or begin a new session.

Filtering records using the Showing option in the upper right corner of the Participant Details screen filters Visits as well as Common Events. The three options for filtering records are Active Records, Removed Records (includes Archived as well), and All Records. When visits or forms are filtered from display, text will display to let you know how many records are hidden.

Form Migration

Definition: Form migration is the ability to transfer data from one Form version to another.

Example: A Data Manager might choose to migrate Form data in order to update the Form to a new version.

Data Managers can migrate Form data on a Participant-by-Participant basis or in a batch.

If multiple versions of a form are available before data has been entered, any user can choose which version to use. The forms with multiple versions will display the default on the form card.

When clicking on the form card, the form will open in the default version.

To edit the form in a version other than the default, click the actions menu and select which version to use.

However, if data has already been entered and a new Form version becomes available afterward, you must have a User Role of Data Manager to migrate Form data. You can migrate data either on a Participant-by-Participant basis or in a batch.

Form Migration Causes the Following:

  • Audit Log: Form migration appears in the Audit Log for the Participant(s) the data was migrated for.
  • Extracts: If data existed in the original Form version that does not exist in the new Form version, that data does not appear on extracts.
  • Response Options: You can remove responses, but the values in the Name field for those that remain cannot be changed. For example, if the options were Mild, Moderate, and Severe (1, 2, and 3) you can remove Severe, but you cannot change Mild from 1 to any other value.

Note: Data will not be deleted from the database due to Form version migration, even if it no longer exists in the new Form version. (See Potential Migration Outcome Examples below for more information.)


  • Data Entry Status: Data Entry Started
  • Study Status: Available
  • User Role: Data Manager
  • Participant Status: Active
  • Event Status: Active (not removed, locked, or skipped)
  • Form Status: Active (not removed)
  • New Form Version: Active (not removed)
  • Previous Form Version: Active (used for initial data entry)


  • The study must contain at least 2 versions of a Form.
  • The study must be published.

Participant-by-Participant Migration:

  1. Click the View button for the Participant on the Participant Matrix.
  2. Click the three dot menu on the form card and select Reassign version.

3. Select the new Form version in the New CRF Version field.

4. Click the Continue button.

Batch Migration:

  1. In the header bar of Study Runner, click Tasks.
  2. Select CRFs under Monitor and Manage Data.
  3. Click the Batch CRF Version Migration button next to the CRF you want to update.

  1. Select the current version of the Form in the Current Version of (Form Name) field.
  2. Select the new version of the Form in the New Version of (Form Name) field.
  3. (Optional) Select a site to update the version at. (The default is all sites.)
  4. (Optional) If the Form is in multiple events, select an Event to update the version in. (The default is all Events.)
  5. Click the Preview button.

  1. Verify the Migration Summary information that appears below the Preview button.
  2. Click the Migrate button.

When you return to the CRF screen, the following message appears under Alerts in the sidebar: Batch CRF version migration is running. You will receive an email once the process is complete

The email you receive has a link to a report of the migration, which provides a list of all Participants and Forms that the data was migrated for.

Potential Migration Outcome Examples:

Example A: More Items in Original Form Version than New Form Version:

Before Migrating from Version A to B:

  • Version A has an item named meditem2.
  • Version B does not have an item named meditem2.
  • Both versions have an item named item1.

After Migrating from Version A to B:

  • Data for meditem2 is migrated but not visible on the Form.
  • Data for item1 is migrated and is visible on the Form.
  • Data from both versions appears on extracts, so there are more items.

Example B: More Response Options Available in Original Form Version than New Form Version:

Before Migrating from Version A to B:

  • Both CRF versions have an item named item1.
  • Version A has the response options X, Y, and Z.
  • Version B only has the response options X and Y.
  • The user selected the response option Z in the original Form version.

After Migrating from Version A to B:

  • Data for item1 is migrated, but it will appear as though no response was selected since response option Z no longer exists in the new Form version.
  • For single-select types: New data will overwrite existing data.
  • For multi-select types: New response options will be added. (If the user selected the response option Z in the original Form version, and that option no longer exists in the new version of the Form, if they then select the response option Y, both the values of Z and Y will be stored in the database.)

Example C: The maximum number of repeats in the original Form version exceeds that in the new Form version:

Before Migrating from Version A to B:

  • Both Form versions have a repeating group named group1.
  • The repeat count in Form A is 5.
  • The repeat count in Form B is 3.
  • The user entered data for 5 repeats.

After Migrating from Version A to B:

  • Only 3 rows of data appear on the Form even though version A had 5 repeats.
  • No additional data can be entered.