Amendment Advisor

The Amendment Advisor compares two Drafts in the same Project and reports the changes that could cause subject data loss when Medidata Rave's Amendment Manager runs the migration between those Draft versions.

It is intended as a focused, pre-deployment risk review. Where the Draft Compare view shows every difference between two Drafts, the Amendment Advisor narrows the report to the specific structural and constraint changes that have been observed to cause data loss during a migration.

Launching the Amendment Advisor

From the Draft List for a Project:

  1. Tick the checkboxes next to exactly two Drafts.

  2. Click the Amendment Advisor button at the top of the list. The button is disabled until two — and only two — Drafts are selected.

The Draft with the earlier creation order is treated as the Source Version (the version currently deployed) and the later Draft as the Target Version (the version about to be deployed). On the results page, the Switch Source / Target link reverses that assignment if you need to inspect the migration in the opposite direction.

Note

Both Drafts must belong to the same Project — the Amendment Manager only migrates between versions of the same study, so cross-project comparisons are not supported.

What the Amendment Advisor checks

Findings are grouped into the following categories. Each category lists the conditions that will be reported when the change is detected between the Source and Target Versions.

Structural removal

Subject data captured against an object that no longer exists in the Target Version cannot be migrated forward.

  • Field removed from form — an active Field in the Source is missing from the Target.

  • Form removed — an active Form in the Source is missing from the Target.

  • Folder removed from matrix — a Folder no longer participates in a Matrix in the Target, even if the Folder definition itself still exists.

  • Form removed from matrix — a Form no longer appears in a Folder of a Matrix in the Target, even if the Form and Folder definitions still exist.

Field data type and constraint changes

Changes to a Field's data format may prevent existing values from being stored under the new constraints.

  • Field data type changed — the Field's data type has changed between formats (e.g. text → integer, date → text). Existing values may fail to convert.

  • Float field converted to integer — a float Field has been changed to an integer Field. Decimal precision in existing values will be silently truncated.

  • Text field max length reduced — a text Field's maximum length has been reduced. Existing values longer than the new limit will be truncated.

Data dictionary

  • Data-dictionary value removed — a coded value present in the Source dictionary is missing from the Target dictionary, leaving any subject data already coded with that value without a matching entry.

  • Field switched from free text to data dictionary — a Field that was free text in the Source uses a data dictionary in the Target. Existing free-text values that do not map to a dictionary entry will be lost.

Form structure changes

  • Form log structure changed — a Form that was non-log (single instance) in the Source is log/repeating in the Target, or vice versa. Existing subject records may not migrate cleanly into the new structure.

Edit-check actions

These actions mutate study structure for existing subjects when the parent Edit Check fires during the migration replay. They are reported only when the parent Edit Check has Bypass During Migration set to False.

  • Add Form action runs during migration — an active Edit Check in the Target has an AddForm action that will fire during migration.

  • Add Matrix action runs during migration — an active Edit Check in the Target has an AddMatrix action that will fire during migration.

  • Merge Matrix action runs during migration — an active Edit Check in the Target has an MrgMatrix action that will fire during migration.

  • Custom Function action runs during migration — an active Edit Check in the Target has a CustomFunction action that will fire during migration.

Reading the results page

The findings table shows one row per detected condition with these columns:

  • Type — the kind of object the finding applies to (Field, Form, Matrix, Edit Check, Data Dictionary).

  • Identifier — a stable identifier for the affected object, generally the OID. Compound identifiers use a slash separator (for example MTX01/VISIT1/FRM02 for a form in a matrix slot).

  • Finding — a short title describing the condition (e.g. Field removed from form).

  • Detail — additional context such as the names of the objects involved or, where relevant, the specific values that may be affected.

You can sort, filter and page through the findings using the standard table controls.

If no conditions are detected the page reports No potential data-loss conditions detected for this migration. This is not a guarantee that the migration will not fail or alter data in other ways — only that none of the conditions listed above were detected. Use the Draft Compare view if you need to inspect the full set of differences between the two Drafts.