Handling eCRF updates after going live

Prerequisite: Please read the following lesson to understand the difference between a revision and a new version:
Viedoc study configuration management

When to do a new version versus a revision

The way of handling protocol amendments and updates/corrections to the eCRF depends on the situation each time. The following table gives a general guideline on when to do a new version versus a revision:

New version	In a new version, all changes to the study design are allowed. However, just because something can be changed does not mean it is a good idea to do so. It is safest to stick to the original structure and design as far as possible. For example, when making changes in the Study Workflow, be mindful of how these changes will affect the dependencies of previous versions. In terms of scheduling and visibility conditions, all events will behave as per the current effective design. Note! The final order of the events as seen in PDF records depends on the dates entered by the user and not on what was programmed in the Study Workflow. A new version is required when: Only future events are to be affected (to not break SDV or signature on previous forms). There are changes to randomization forms (using the built-in randomization feature). These forms are locked and cannot be unlocked. Viedoc Me forms are locked upon receipt. These forms must be unlocked before a revision can be applied. Therefore, it is best to change Viedoc Me forms in a new version. Remember to also update translations if necessary.
Revision	In a revision, the types of changes that can be made to the design are limited: a. It is not possible to add items with the same ID, and a deleted item cannot be brought back. b. Item types cannot be changed—a number cannot be converted to a string, and a radio button cannot be converted to a checkbox. In general, these changes must be done in a new version. Ask support for the best advice if the solution isn’t obvious. A revision is required when: Forms have been saved with subject data and the forms require an update.
Both	Sometimes an update to the eCRF will require both a new version and one or more revisions.

New version

In a new version, all changes to the study design are allowed. However, just because something can be changed does not mean it is a good idea to do so. It is safest to stick to the original structure and design as far as possible. For example, when making changes in the Study Workflow, be mindful of how these changes will affect the dependencies of previous versions. In terms of scheduling and visibility conditions, all events will behave as per the current effective design.

Note! The final order of the events as seen in PDF records depends on the dates entered by the user and not on what was programmed in the Study Workflow.

A new version is required when:

Only future events are to be affected (to not break SDV or signature on previous forms).
There are changes to randomization forms (using the built-in randomization feature). These forms are locked and cannot be unlocked.
Viedoc Me forms are locked upon receipt. These forms must be unlocked before a revision can be applied. Therefore, it is best to change Viedoc Me forms in a new version. Remember to also update translations if necessary.

Revision

In a revision, the types of changes that can be made to the design are limited:

a. It is not possible to add items with the same ID, and a deleted item cannot be brought back.
b. Item types cannot be changed—a number cannot be converted to a string, and a radio button cannot be converted to a checkbox. In general, these changes must be done in a new version. Ask support for the best advice if the solution isn’t obvious.

A revision is required when:

Forms have been saved with subject data and the forms require an update.

Both

Sometimes an update to the eCRF will require both a new version and one or more revisions.

Best practices for handling eCRF updates

General

Click the Validate button often. The design should not be published with errors.
Use the Study Workflow to control visibility. The point-and-click visibility settings are much easier than writing the equivalent JavaScript code.
Preview the form in Study Workflow to see how it will look for a specific event/activity.

Items and IDs

Consider hiding items instead of deleting them. If an item is deleted it can never be brought back in that same version. Instead, change the item’s visibility to Hide always. If the item needs to be brought back, then the visibility can easily be changed back to Show always.
If an ID needs to be changed, consider changing the output ID instead:

For items with code lists—radio buttons, dropdown lists, and checkboxes—each code list option consists of two parts:

The label
The code

For example:
Adding an entirely new option in a new/revised design version is okay. However, when it comes to changing the existing labels or codes, keep the following in mind:
Labels - Editing an existing label while keeping the same code value will cause a data split in the export. This will be indicated by ItemID_n where "n" is the number of versions there are of the code list. If there are different labels for the same code value, this may cause errors in your design.

Code values - The codes of the existing options should not be changed. Codes should be unique. Thus, make sure not to add a code list that existed previously or was later removed.
Be mindful of items that will require updates. For example, a dropdown lists labelled Patient consented under protocol version:—if such an item was placed on the starting form, then SDV and signatures would break every time this item was updated.

New versions

Try to keep the number of new versions to a minimum. For example, if there are 10 versions of the eCRF, and all require a revision, then you’ll need to perform 10 revisions (one per version).
In Admin, when assigning a new version, the suggested practice is to always assign the version on the same date as the last one. Check the audit trail of when the previous versions were assigned. For example, if version 1.0 was assigned on 2020 JAN 01, then version 2.0 should also be assigned on 2020 JAN 01. This ensures that version 2.0 is used regardless of the event date. Please see the lesson Viedoc study configuration management for examples and consequences of version management and dates.

Revisions

Be aware that if a revision affects data integrity in any way—even grammar corrections or adding an option in a dropdown menu—SDV, signatures, and review flags will break.
During a revision, if form updates are approved in a batch but fail to apply to all forms, then the approval message will appear again. The updates could have failed either due to forms being locked, or the user not having view/edit permissions for the revised items.
If a form is locked, then the updates applied in a revision will not take effect. The form must be unlocked by a user with lock permissions.
If an item is removed in a revision—either by deletion or by changes to its visibility conditions—and data have been stored for this item, the removal will show in the audit trail.
In Admin, make sure that revisions aren’t accidentally assigned as versions! You do not enter a date of assignment for a revision; it uses the previously set date. It is important to understand the difference between “assigning a new version” and “applying a revision”.

Doing a revision

Note! All steps below are performed on the production server. After going live, the training server should only be used to test a proof of concept.

1	Do an Excel export of all forms that will be affected by the update. Select the Event dates and Review status options. The Review status option is to check for impact to signatures and SDV, as well as check if forms are locked. The Event dates options is to check if events have been initialized under a design or not.
2	The effective design version can be found in the export for each form under the column Design version. Use this information to see which versions will need to be revised.
3	Go to Designer and download a complete configuration report for each version that needs revision.
4	In each configuration report, check for items that will be affected (do a Ctrl+F search of the item’s ID). Check for dependencies on visibility conditions, functions, and edit checks. For more information, see Configuration report.
5	Make changes as appropriate in each version.