New Features in 21R3.5
Restore Environment from File, Query Scoping for Repeating Objects, and more...
Release Date: March 4, 2022
We are pleased to bring you the following new features in this week's release. See a summary of feature enablement for this release below. Information on developer features (REST API) is in the Developer Portal.
Data Entry
Features in this section are changes to the Data Entry tab, a working area for investigators and clinical research coordinators to enter study execution data.
Enablement Change: Removed Ability to Opt Out of Item-level Intentionally Left Blank
With this release, we removed the ability to disable Item-level Intentionally Left Blank, to prevent issues with Item Group-level Intentionally Left Blank. As part of this change, the Item-Level Intentionally Left Blank feature is now enabled in all vaults where it was previously disabled.
Enablement
This change applies automatically. If Item-level Intentionally Left Blank was not enabled in your vault, it is now enabled.
Clinical Coding
The following are new features for Coder, the clinical coding area for Vault Coder.
Enablement Change: Unique Terms Report
With this release, the Unique Terms Report feature is now automatically enabled in all vaults.
Enablement
This feature is automatically available.
Study Design & Configuration
Features in this area apply to Studio, the study design and configuration area for Vault EDC.
Query Scoping for Repeating Objects
We enhanced the scoping of queries when the targeted identifier has repeating parts. Vault will open the query on the Item that is actually generating the query, provided that this identifier is also present in the rule expression. Prior to this release, Vault would open the query on the first instance of the Item.
Enablement
This change applies automatically in new Studies (created after 22R1). For Studies created prior to the 22R1 release, this feature must be enabled using the Enhanced Query Scoping field on the study’s Study Configuration record.
Event Window Updates
With this release, we made changes to the method for configuring event windows to alleviate difficulty in configuring windows for repeating Event Groups (cycles).
Study designers can now choose from the following for Offset Event (as radio buttons):
- Previous Event
- Specific Event (allows users to select the Offset Event Group and Offset Event)
- None
Secondly, study designers can now override the event window configuration for Events in repeating Event Groups. This is in the updated Repeating Event Overrides dialog, accessed by clicking Repeating Event Override (Labels, Windows) in the event’s Properties panel (formerly labeled “Repeat Labels”).
With the release, we are automatically migrating existing Studies to the new model. For Events where the Event Offset hasn’t been selected, Vault will default to None. If the Event does have an assigned offset event, Vault creates a new record linking the chosen Offset Event to the Event Group containing that Event. If the Event is used across multiple Event Groups, Vault automatically selects the Event Group prior to the current event’s Event Group (and most recently, if there are multiple Event Groups with the Offset Event that occur prior to the current Event Group). For example, if the current Event Group is 501, and the Offset Event belongs to 201, 301, and 701, Vault uses the 301 event group, as it is before and most recent to 501. Entries in the Overdue Days property remain if set, regardless of the existence of an Offset Event.
As part of this enhancement, we added the Repeating Event Groups worksheet to the Study Design Specification to track configurations specific to repeating Event Groups. This worksheet has the following columns:
- Event Group Name
- Sequence
- Default Display
- Offset Days
- Day Range Early
- Day Range Late
Use Case
These changes allow users to define windows for Events within repeating Event Groups (cycles). They also reduce study development time by providing the ability to calculate the window based off of a previous Event, instead of selecting a specific Event each time.
Enablement
These changes apply automatically. Because we upgraded the configuration of existing event windows, study designers should review their configurations where an Event is used in multiple Event Groups after the release, to ensure that the windows were migrated correctly. If possible, organizations should identify these Studies prior to the release to prepare for these changes.
Study Administration
Features in this section apply to EDC Tools, a study-level administration area for Vault EDC.
Restore Study Environment Enhancements
With this release, the Delete action in the Actions menu for Study Environments has been renamed to Delete Environment. Users can use this action to delete a Study Environment. This option is not available for production environments and will permanently delete a Study Environment, including Study Definitions and Data. Users must enter the Study Name to complete deletion.
In addition, Vault will automatically back up the Study Design before deleting the study environment. The backed-up file will be available in Deployment History.
Use Case
This enhancement will clearly distinguish each inline action menu.
Enablement
This applies automatically.
External FTPS & FTP UI Enhancements
With this release, we refreshed the UI for creating Connections to FTP servers in EDC Tools. We updated our data model for storing external connections. Vault CDMS now supports the following connection types:
- Veeva Vault FTPS: Used to send files to a Veeva Vault FTPS server
- External FTPS: Used to send files to an external FTPS server outside of Vault
- CDB Workbench: Only enabled for Workbench customers to send files to external FTP or FTPS servers
To access the FTP dialog, users need the Manage FTP permission.
For External FTPS type connections, users need their own FTPS server enabled using Passive FTPS. Users need their firewall ports open to ports TCP 21 for the control channel and 56000-56100 for the data channel. If users need a specific port range open, there is a process for submitting a request and getting security approval.
For the Veeva Vault FTPS, users need access to a Vault FTPS server with TCP ports 21 and 56000-56100 open.
To configure a CDB Workbench connection, the vault must contain the CDB application. As part of this enhancement, the process to create an FTP destination for CDB exports has changed.
Use Case
Users can send exports like Study Data Extract and Code Request exports to their external FTPS server in addition to the Veeva Vault FTPS server.
Enablement
The updated FTPS and FTP UI is enabled automatically. External FTPS connections are automatically available for qualifying FTPS servers.
Deployments
Features in this section are enhancements to deployment functionality in Vault CDMS.
Restore Study Environments
With this release, users can download the backup of the study design for a deleted study environment and use it to restore the study design. An EDC Tools user can select the Restore action from an environment’s Actions menu. Then, they can select Restore from File in the Restore Study Design dialog and select the backup file. Note that this action only restores the study’s design. It doesn’t restore the study data. There is no change in the Restore from Environment flow.
Use Case
If a user deletes an environment in error, this enhancement will restore the study design. The Restore option is only available in a development (DEV) environment.
Enablement
This feature is automatically available.
Clinical DataBase (CDB)
The following are new features for the CDB application, the Vault CDMS solution for data cleaning and reporting.
Availability: Clinical DataBase (CDB) is only available to CDB license holders. Contact your Veeva Services representative for details.
Import Change Approval
To ensure that data being imported into CDB doesn’t change from the approved format and structure, CDB detects any changes to package configurations from one load to the next for each third party Source.
If the system detects changes in configuration at the package, file, or blinding level, or changes in the CSV file structure, CDB pauses the import process. The package isn’t processed and enters the Paused status until a user with approval rights either approves or rejects the package. If the user approves the package, CDB records the approval reason and imports the data package. Once a package is approved, CDB notifies subscribers to the approved change via email. CDB displays a change indicator on all associated Listings and Views. Users are able to dismiss this indicator and download the form change log for any listing or view. If the user rejects the package, CDB records the rejection reason, marks the package as Rejected, and assigns it the Not Imported status. CDB then reverts to the last successfully imported data package for the Source.
When a package is in the Paused status, all other uploaded packages for that same Source enter a queue and will wait for the paused package to be approved or rejected. Once the paused package is approved or rejected, CDB skips to the last queued package for processing. Any packages between the last paused package and the last package in the queue aren’t processed. For example, if “Package 1” is uploaded and paused, then packages 2-5 are uploaded while “Package 1” is still in the Paused state, once “Package 1” is approved or rejected, CDB will skip to “Package 5”, leaving packages 2-4 unprocessed.
For the first uploaded package in a new Source, CDB automatically applies the Paused status, and a user must approve or reject that first package before any data from that Source appears in the system.
For packages requiring approval, Workbench now includes a Package Detail panel with tabs for Differences and Associated Objects. The Differences tab displays the changes in the manifest between the current and previous packages. Users can review the previous and current value of the changes that they’re approving. The Associated Objects tab displays the Export Definitions, Listings, and Views that the changes in the package may potentially impact.
To approve or reject an import package requires the Approve Import permission, which is by default assigned to the standard CDMS Super User and CDMS Lead Data Manager study roles.
Use Case
Allowing the system to automatically detect changes in an import package helps prevent accidental or unintentional changes from occurring. For example, a change in the blinding configuration can potentially unblind a study. Requiring approval prevents changes being applied before stakeholders are aware and able to address needed downstream updates.
Enablement
This feature is automatically enabled.
Export Change Detection & Updates
An Export Definition consists of Export Listings, that are snapshots of the parent listings. When a parent listing is updated, in some cases, the export may become out of sync with the parent, leading to outdated listing structure in export packages. For example if upstream, a custom listing design was updated, any Export Definitions that reference that custom listing will still reflect the original listing design. If the CQL is modified for an Export Listing, that listing is also considered impacted, or out of sync, with the parent listing.
With this feature, CDB flags Export Definitions that have been impacted by changes. CDB provides a quick filter to easily narrow the export definition list to only those that have been impacted. When a user opens an Export Definition, CDB shows an indicator on Export Listings that are impacted by changes. Users can use the quick filter to display only the impacted Export Listings. The impacted flag indicates that the export listing’s CQL is out of sync with its parent listing’s CQL. Users can sync select Export Listings with their parent listings, or in bulk as a batch action. Once synced, CDB removes the impacted flag from the listing. Optionally, users can review the differences between the two CQL statements without navigating away from the Export Definition.
Use Case
This feature allows users to easily identify and sync the Export Listings that have been impacted by changes to the CQL of their parent listings, reducing the possibility of outdated data sets in export packages.
Enablement
This feature is automatically enabled for Export Definitions created after this release. This feature is unavailable for Export Definitions created prior to the 21R3.5 (March 2022) release.
New @HDR & @Form Attributes
With this release, we added the following new attributes for CQL:
@HDR.Subject.Arm@HDR.Subject.Cohort@HDR.Subject.Substudy@HDR.Subject.EndOfStudyDate@HDR.Subject.EndOfTreatmentDate@HDR.Subject.EnrolledDate@HDR.Subject.InitialConsentDate@HDR.Subject.LostToFollowUpDate@HDR.Subject.RandomizedDate@HDR.Subject.ScreenedDate@HDR.Subject.ScreenFailedDate@HDR.Subject.StartedFollowUpDate@HDR.Subject.StartedTreatmentDate@HDR.Subject.WithdrawnDate@HDR.Event.Version
Enablement
These CQL attributes are automatically available.
Feature Enablement Summary
| Feature Name | Configuration | Dependencies | Day 1 Impact to Primary Users | Users with Day 1 Visibility |
|---|---|---|---|---|
| Data Entry | ||||
| Enablement Change: Removed Ability to Opt Out of Item-level Intentionally Left Blank |
|
|||
| Clinical Coding | ||||
| Study Administration | ||||
| External FTPS & FTP UI Enhancements | Whitelisted IP Address & Port Range |
|
||
| Study Design & Configuration | ||||
| Query Scoping for Repeating Objects |
|
|||
| Event Window Updates |
|
|||
| Deployments | ||||
| Restore Study Environments |
|
|||
| Vault CDB | ||||
| Import Change Approval |
|
|||
| New @HDR & @Form Attributes |
|
|||
Enablement Legend
- Configuration: This field lists the location(s) where configuration for this feature occurs, for example, "Studio" or "EDC Tools". "Support" indicates that this feature must be enabled by Veeva Support, and "Vault Admin" indicates that configuration must be performed by a Vault Owner in the vault's Admin area.
- Dependencies: This field lists any dependencies required to use this feature, for example, Labs or Expression Engine V2. The other columns assume that the dependencies are enabled/in use.
- Day 1 Impact to Primary Users: This feature is visible and available to one or more primary user teams (Site Users, Clinical Team, and Coders) on day 1. Otherwise, this feature is either only visible to study designers or administrator users, it requires configuration before it is visible to primary users.
- Users with Day 1 Visibility: This feature is visible to these users on day 1 if no configuration occurs.