Data can be reviewed using the Participant Matrix, Queries screen, 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.

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.

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.

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.

 

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 the toggles next to 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.

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 may not be customized, or if it is, 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.

To clear a custom view, click anywhere on the Custom View On button and all view customizations are removed for that participant.

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 there are multiple versions of a Form available before data has been entered, any user can choose 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.
  • E-Signature Status: If a Participant Casebook or Event was signed before the Form migration, that signature is removed, and it must be signed again.
  • SDV Status: If SDV was already performed, the status resets to needs source data verification
  • 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.)

Requirements:

  • 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)

Prerequisites:

  • 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 across from the Participant on the Participant Matrix.
  2. Click the Enter Data button, and enter data.
  3. When finished entering data, click the Close button or the Complete button.
  4. Click the Reassign CRF to a new version button.

  1. Select the new Form version in the New CRF Version field.
  2. Click the Continue button.

  1. Verify the data mapping information on the Confirm CRF Version screen, and click the Submit button.

Batch Migration:

  1. In the header bar of Study Runner, select 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

You will receive an email with 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.