Collecting data with mirrored table rows from scheduled events to (S)AEs

Available with version 4.10.0.

Learn how to work with mirrored table rows during data collection, enabling seamless transfer of table data- such as Concomitant Medications or lab results - from scheduled event forms to (S)AE forms. 

TABLE OF CONTENTS

• 1. Understanding mirrored table rows in data collection
• 2. Mirroring data into your (S)AE form
• 3. Managing changes in the source table
  • 3.1. Impact of source table updates on (S)AE forms
  • 3.2. Deleting rows in the source table
• 4. Trouble shooting and best practices
  • 4.1. Common issues and solutions
  • 4.2. Best practices for site users

1. Understanding mirrored table rows in data collection

Mirrored table rows functionality appears as an integrated part of your (S)AE form workflow. When configured by study designers, this feature allows you to select specific table rows from scheduled event forms and mirror them directly into your (S)AE forms, where they become actual (S)AE data with full form integration.

Once selected and mirrored, table row data behaves like any other field in the (S)AE form. This means it:

• Contributes to form completion percentages.

• Triggers all configured notifications.

• Follows validation rules and automated query checks.

• Respects system rules (e.g. no mirroring when the form is locked; updates via the source table can break existing signatures and SDV status).

• Initial mirroring and subsequent updates via the source table are fully tracked in the audit trail with detailed change logs.

• Will be part of source data export (scheduled events) and (S)AE data export.

2. Mirroring data into your (S)AE form

In your (S)AE forms, mirrored tables appear as dedicated tables that are linked to source data from scheduled events.

	Mirrored tables are easy to recognize: they include navigation links to the original source data. You can open the source form directly, but make sure to save any changes in the (S)AE form first.
	To mirror data, click into the table or use the button “Mirror data from {{source table}}” (e.g. “Mirror data from Medication”). A popup with available rows will appear.
	The popup header shows the step and form name of the source for better context. Below, you’ll see a preview of the source table with its data.
	Select one or more relevant rows that you want to mirror into the (S)AE.
	Confirm your selection by clicking Save at the bottom right.
	The selected rows are now mirrored into the (S)AE destination table and are treated as part of the (S)AE. Queries can be raised on individual fields, but the data cannot be edited here - updates must be made in the source table. ⭐ Good to know: A column called "Source" is added by default, showing the original row label from the source table to help you identify the origin of the mirrored data.
	You can remove mirrored rows from the (S)AE form at any time. ⚠️ Important: Removing a mirrored row only unmirrors the data. The original entry in the source table remains unchanged.

3. Managing changes in the source table

3.1. Impact of source table updates on (S)AE forms

When data in these mirrored rows is updated, the changes are immediately reflected in the (S)AE form. This impacts:

• Field values in the mirrored row

• The form’s completion status

• Modification timestamps and corresponding audit trail entries

• Validation checks or dependency triggers applied in the source table

• Signature status (updates break existing (S)AE form signatures)

• SDV status (if the destination table or (S)AE form was fully SDVed, it becomes invalid)

• Exception: locked or 100%-required forms (updates are still applied even if the (S)AE is locked or set to “only save on 100%”)

3.2. Deleting rows in the source table

Rows in the source table (scheduled event form) cannot be deleted while they are mirrored to (S)AE forms. To delete a row completely, it must first be unmirrored from all (S)AEs.

4. Trouble shooting and best practices

4.1. Common issues and solutions

Issue 1: Cannot see expected source data for mirroring

• Solution: Verify that source data has been entered and saved in the scheduled event form
• Check that you have appropriate access rights to the source form

Issue 2: Mirrored data appears incomplete

• Solution: Confirm that all required fields in the source table are completed
• Review any validation errors in the source form

Issue 3: Synchronization options not available

• Solution: Check if the source data has actually been updated since mirroring
• Verify your access rights for both source and destination forms

4.2. Best practices for site users

Following these best practices helps ensure data quality, regulatory compliance, and efficient workflow management while working with mirrored table rows functionality:

• Complete source data entry before starting (S)AE forms when possible
  
• Review source data completeness before mirroring
• Mirror data promptly after source data entry to maintain consistency
• Use navigation features to verify data accuracy between source and destination
• Verify that all relevant rows have been selected for mirroring
• Coordinate with monitoring teams regarding mirrored data review processes