Viedoc Post-Live Changes Webinar Q&A
This video is a recording of the Best practices for how to handle post-live changes webinar, part of the "Working Smarter series":
Cannot see the video? Click here.
Best practices for how to handle post-live changes - Q&A
Item Visibility and Hiding
Q: I have a field that is no longer needed. Should I hide it instead of deleting it?
A: It’s generally a good idea to change the visibility of this item to “HIDE” – always, rather than delete it. It will still show in the export, but if the sponsor changes their mind and wants it back, you can easily make it visible again. Whereas if you delete it, you cannot bring it back with the same ID. If you decide you still want to remove it at the end of the study, then you can delete it at that time.
Q: If you hide items, do they still show in the export?
A: Hidden items will still show in the export (and audit trail, if the item group is visible). If an item is deleted in a fully customizable version, then it will not show in the export.
Q: If the hidden items are shown in the export, how should we filter them?
A: Add the word “hidden” (or equivalent) to the output label.
Q: When hiding items, would it be good idea to uncheck the “required” option for the item?
A: Yes, this is a good point. If hiding the item, it is a good idea to make it not-required.
Q: What will happen if I "Hide to all Roles" in order to hide/remove an item? Is this option "Hide to all" to be used in any case?
A: You’ll generally never want to use “Hide to all roles.” This will also hide the entire PDF of the form to ALL roles, and there should always be at least one role that has access to the PDF. Please read here for how role visibilities should be handled: Blinding in Viedoc
Database Splits
Q: What is a database split? How does it happen? What are the consequences?
A: A database split is when you unintentionally change the database structure such that it adds columns in the data export. This typically happens when an item ID or label changes in the middle of the study. There will be one column for the original data, and then a new column for the changed item and the newly entered data. Thus, one column will be populated from the beginning of the study and then empty for the rest of the study, and the other column will appear blank from the beginning of the study and populated after the change. They are disruptive to data managers, especially if they have hard-coded reports based on the export structure. For example, imagine that you’re collecting the date in a single date field. Then later on in the study, it is decided to capture the date in three separate fields for year, month, and date. This will result in a database split where you have one column for the complete date and three new columns for the year, month, and date items. See the example below, where even the month doesn’t match the number format of the other columns. This isn’t something that can’t be handled, but it’s tedious data cleaning for the data management.
|
CompleteDate |
Year |
Month |
Date |
|---|---|---|---|
|
2021-12-16 |
|||
|
2019-01-16 |
|||
|
1984-05-26 |
|||
|
1982-07-25 |
|||
|
2001 |
MAR |
1 |
|
|
2014 |
APR |
15 |
|
|
2020 |
MAY |
30 |
Q: Can we get an exhaustive list of things that cause a database split in the eLearning please?
A: A database split will result from the following:
- The site not upgrading the form changes (the affected items will appear in another column with an _2 suffix). This will resolve once the site has approved the changes (i.e., will not be a permanent problem that requires fixing at the end of the study).
- Changing the label of an item in a fully customizable version
- Changing the code list values for a check box
- Changing an item (using same ID) from one data type to another.
Time of assignment
Q: What are some example of how “Time of assignment (UTC)” affects what happens when a new version is assigned.
A: Let’s assume version 1.0 was assigned at 2025 JAN 01, and version 2.0 was assigned 2025 SEP 19. In this situation, the effective design from 2025 JAN 01 to 2025 SEP 18 will be version 1.0, and then version 2.0 from 2025 SEP 19 to the current date. If a site was late entering data, and initiated event date forms in August, then version 1.0 would be applied to the forms for that event. Furthermore, if a site tried to enter an event date earlier than 2025 JAN 01, they would not see any forms because no design is active during that time.
Thus, if you want version 2.0 to be effective across ALL dates from 2025 onwards, then it should be assigned on the same date as when version 1.0 was assigned: 2025 JAN 01. Then all newly data entered will be version 2.0. However, if forms were originally initiated on version 1.0, then the only way to update them is with a revision to version 1.1. The design version is “burnt-in” once that event is first initiated. It is the event date form (and thus, the EventDate system variable) that determines which version is used. Thus, you must understand which versions are active during which time periods. If you follow our general advice to always apply versions on the same exact date (January 1st of the first of year when the study started), then there is less to think/worry about.
NOTE: forms do NOT update when a new version is assigned! That is what revisions do.
Q: Is there a scenario where we can change the time of assignment? What should I do if I accidentally assigned the design on the wrong date?
A: You cannot change the time of assignment, but you can assign the design to more times. In the example above, where version 2.0 was (perhaps accidentally) assigned on 2025 SEP 19, while version 1 was assigned on 2025 JAN 01, you can make version 2.0 effective across all dates by assigning version 2.0 on 2025 JAN 01. Then version 2.0 will be effective from 2025 JAN 01 to 2025 SEP 18 and then again from 2025 SEP 19 onwards.
Q: RE: Time of assignment - In cases of Protocol Amendments, it would make sense to use Protocol Amendment approval dates rather than same Effective Date as previous version, correct?
A: You probably want the forms to match the design version of the study that the subject has consented to, not necessarily the version that was active when the visit actually happened. If the subject has consented to the latest protocol version, then it may make sense for all their previous data to also apply to that latest version as well, and thus, for the latest study design in Viedoc to be effective across all dates (not merely when the latest protocol version was approved). People tend to equate the study design with the written protocol. And while these two things do mirror each other, they are philosophically different things. If you disagree with this outlook, however, it is not a problem to assign the study design version related to a protocol on the date of the actual protocol approval. But understand that that you may be more likely to experience database splits or other design inconsistencies (albeit from obscure, hypothetical scenarios). In short, ask the sponsor if they have an opinion for how retroactive the changes to the study design should be.
Form and Item Changes
Q: Is it a problem to have specific forms still on old versions when they are not affected by a revision? Especially locked forms – should I unlock all forms before a revision?
A: Locked forms will automatically upgrade to the latest version if the changes do not affect data integrity. Otherwise yes – forms must be unlocked to be upgraded.
Q: I accidentally used a check box when I should have used a radio button. How do I fix this?
A: These are different item types. This means that, even if you make a new version, hide the check box and replace it with a radio button using the same ID and label, the database will still be split. However, this is most likely the best way to handle a change like this. As we do not recommend deleting items.
Q: If you update the output field ID, will it be displayed in the annotated CRF?
A: No, the ONLY place it will change is in the export (and in the complete configuration reports and ODM files where the output ID is specified). The mechanics of the item for all data checks, visibility conditions, and other exports will still behave as per the original ID.
Other Questions
Q: What's the difference between “apply revision” and “assign design?”
A: You assign the design when you want the site to currently work as per that design. For example, if it’s currently on version 1 and you want it to be on version 2, you must assign version 2 to the site. You apply a revision when you want the forms to that version to upgrade. For example, if there are many forms on version 2.0 and you want to apply version 2.1 to them, you must apply the revision to those forms. If you merely assign version 2.1, then you’ll just be making version 2.1 the current effective design, not upgrading the forms. When you assign a design, they system will prompt you to enter a date for the design to start being effective. While when you apply a revision, the system will not ask for a date. The forms are already effective, and you are upgrading them to the latest revision version.
Q: Would ePROs in multiple languages be a valid reason for Sites being under different design versions? For example, Site 01 is approved to use English and Spanish but Site 02 is only approved to use English.
A: Viedoc Me (our ePro) has good functionality for handling different languages (section 6 here: https://help.viedoc.net/c/e311e6/a06618/en/), so no – sites using different languages should probably still be on the same design.
Q: Is it possible to get warnings in Designer if changes that are expected to be the same across all revised versions are not matching?
A: We have added more “warnings” in Designer lately and intend to add more. Currently there are red errors that block the design from being published and yellow warnings that still allow the design to be utilized. Some clients, however, have SOPs to not allow warnings (in anything they do!), so we must be careful about this.