New Features in 21R2.4

Empty Form Link Indicator, Study Data Extract Enhancements, and more...

Release Date: October 15, 2021

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.

Study designers now have the option to enable a Warn When Empty setting when creating a Form Link in Studio. When enabled, the Form Link tab is highlighted in red when no Form Links have been added. Vault stops displaying the highlight when a site user adds at least one Form Link.

Use Case

Site users are less likely to forget to add a Form Link before moving on to other Forms/Subjects.

Enablement

A study designer must enable the Warn When Empty setting on the Form Definition in Studio.

Unsetting ILB Restores Default Data

When users unset a form as Intentionally Left Blank, forms that contain defaulted data will restore the defaulted values with this release.

Use Case

Site users no longer need to perform the Reset Form action after unsetting Intentionally Left Blank to restore defaulted item values.

Enablement

This feature is available automatically.

Study Design & Configuration

Features in this area apply to Studio, the study design and configuration area for Vault EDC.

Progressive Display Enhancements

This is an enhancement to the current feature that allows users to configure multiple dependent Items for progressive display from a single controlling Item. Previously, users would have to configure each Item independently, now users can select the controlling Item and select all dependent Items and Item Groups for that controlling Item simultaneously. Users can also edit and remove dependent Items and Item Groups from the controlling Item, rather than having to visit each individual item.

Use Case

This feature increases efficiency when configuring dependent progressive display Items, particularly when there are many dependent Items and Item Groups.

Enablement

This feature is automatically available in Studies using Rules V2.

Study Administration

Features in this section apply to EDC Tools, a study-level administration area for Vault EDC.

Audit Trail Export by Site

With this release, users can now export the audit trail for an entire site by running the new Audit Trail Export by Site job available in EDC Tools. Up to ten Sites can be selected for a single job. Like the Audit Trail by Study and Audit Trail by Site jobs, the output of this job will contain a .CSV file for each Subject in the selected site(s). The columns and contents of the .CSV files remain unchanged from previous releases.

Use Case

Users no longer need to run a full Study audit trail export or select Subjects individually to retrieve the audit information for an entire Site.

Enablement

This feature is available automatically.

Audit Trail Export Filtering

Audit Trail Exports generated from EDC Tools now allow for optional filtering to limit the information included in the exported audit .CSV files. When running an Audit Trail Export, users can now choose to apply a Date Range and/or User filter. For Date Range, users can specify a full date range, or only supply a start or end date to include audit information after or prior to the selected date. Applying a User filter limits the exported audits to only include the actions performed by the selected user(s). Filtering is available for all Audit Trail Export jobs (Study, Site, and Subject).

Use Case

Users can now generate an Audit Trail Export that only the subset of audit entries need compared to doing an export of all audit entries.

Enablement

This feature is available automatically.

Extract Job Governor

Under the extract job governor, the following rules have been implemented for running ad-hoc and scheduled extract jobs:

  • An extract job can only be started if there is no other job of the same type already running, meaning that if there is an ad-hoc Form Progress Listing running, users can’t start another ad-hoc Form Progress Listing. This rule does not affect scheduled extract jobs and they can run in parallel to ad-hoc jobs
  • Only two jobs of each extract type can be scheduled per study (two Study Data Extract jobs, two Form Progress Listings, etc.)
  • Extract jobs of the same type have to be scheduled at least one hour apart
  • Jobs scheduled in non-production Vaults require a number of active periods to be selected, which is used to set an expiration date (ex: 5 active periods on a daily job means the job will run for 5 days). Once the scheduled job has reached its expiration date, it will no longer run and the user that scheduled the job will receive a notification
  • After a study is locked, scheduled jobs will continue running for seven days and then expire. Ad-hoc jobs can still be run after a study is locked

In addition, users with the Manage Study Priority permission can set a production instance of a study as a priority. Once the user selects this option for a study, all new extract jobs for the study will be run in priority over jobs from other studies. Jobs from non-priority studies will still run in parallel, but priority jobs run in a dedicated “priority queue” with more resources allocated

Only two studies can be marked as priority at the same time. Priority expires after seven days and the system will notify the user that set the priority of the expiration. Users can set a priority for the same study after the current priority expires.

The CDMS Lead Data Manager and CDMS Super User standard study roles have the Manage Study Priority permission by default.

Extract jobs include the Study Data Extract, the Subject Progress Listing, the Form Progress Listings, the Query Details Listing, and the Event Progress Listing.

Use Case

With a broader use of the Study Data Extract and the addition of progress listings in 21R3, the volume of extract jobs running at the same time is going to increase significantly. The goal of the job governor is to ensure that a reasonable amount of jobs can be run ad-hoc or scheduled for each study in a given Vault.

Enablement

This feature is automatically enabled.

Study Data Extract Enhancements

The following new columns have been added to the 21R3 version of the SDE to the SYS_FORM and SYS_ILB datasets:

  • Last Signature Date added to SYS_FORM
  • Item Definition and Lab Analyte Name added to SYS_ILB

Use Case

Allows users to retrieve additional metadata information to use in downstream analysis.

Enablement

These changes apply automatically.

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.

CDB Views

With this release, users can create Views, which are virtual tables based on the result set of a CQL statement. They can combine a View with other Views and Forms to create View Listings. Each view contains rows and columns, where the fields are from one or more real tables in the study database. A View Listing always shows up-to-date data, decorations, and access to the associated queries. Each time a user queries a view, Workbench recreates the data, using the view’s CQL statement.

Potential use cases for views include:

  • Restricting Data Access: Views provide an additional level of table security by restricting access to a predetermined set of rows and columns.
  • Hiding Data Complexity: A view can hide the complexity that exists in a multi-table join.
  • Rename Columns: Users can rename a column within the context of the View, without affecting the base tables.
  • Store Complex Queries: Users can store more complex CQL in Views.
  • Simplify Commands for the User: Users can select information from multiple tables without needing to know how to actually perform a join.
  • Multiple View Facilities: Workbench supports different views created on the same table for different users.

Use Case

Views provide a way to store referenceable, complex CQL in order to simplify and provide consistency across listings within a study.

Enablement

This feature is available automatically, but a user with the appropriate permissions (either the CDMS Super User study role or a custom Study Role with the Create View permission) must create Views for standard Workbench users to use them.

Additional UI Filters for Listings

Workbench users can now apply data type aware filters to listings directly from the listing grid. Data type aware filters include options to filter by the default unit for measured results, a date picker for date and datetime columns, and value selectors for both boolean and codelist defined columns.

Use Case

Data type aware filters enable data managers to quickly access data of interest directly from the listing grid without having to edit the underlying CQL directly.

Enablement

This feature is available automatically.

Ingestion Audit Log

With this release, CDB provides the ability to view an audit log of when and who loaded import packages. If available, Workbench also includes the Package Transform Date, Import Date, and Date Applied for each package. This audit log is shown in the new Import > Audit Log page. Users can filter the audit log by Source and Loaded Date Range (within Users can download the audit log as a CSV file.

Import If available, Package Transform Date, Import Date, and Date Applied will also be provided. A new tab, Audit Log, has been added to the Import page where the user will be able to specify the Source and Loaded Date Range of the import packages that they want to retrieve the audit log for. The user will have the ability to download the audit log results as a CSV. The Loaded Date Range cannot exceed a range of 90 days.

Note that the audit log begins recording events starting at the time of release.

Use Case

This feature allows for the ability to keep track of what was loaded into CDB, when, and by whom.

Enablement

These changes apply automatically. To retrieve the audit log form the Imports page, a user must have the View Import permission. Note that the audit log begins recording events starting at the time of release.

Key Manager

Workbench now supports key mapping. Users who can access Import > Key Mapping (users with the Manage Key Mappings permission) can download a key mapping template for either the Study, Site, Subject, or Event. Workbench includes supplemental data in the ZIP file depending on the type of key mapping template. The supplemental data for each key mapping type is as follows:

  • Study: A CSV file that lists the Study Name and the External ID of the study.
  • Site: A CSV file that lists the Site Number and Site Name for all the Sites in the Study Environment.
  • Subject: A CSV file that lists all the Subjects in the Study.
  • Event:
    • A CSV file that lists all the Event Definitions, based on the last export from EDC.
    • A CSV file that lists all the Event Group Definitions, based on the last export from EDC.

Key maps are defined for a Study on a Source/Key Mapping Level, so it is possible to have up to four (4) different key mappings per Source. Any updates for a specified Source and Level combination replace existing mappings for the same Source and Level combination.

Use Case

There are scenarios where the 3rd party data may have different values for a Study, Site, Subject or Event in the data file that don’t match any EDC values, based on how the Study is configured in EDC. Instead of having the data vendor modify the data, which can be expensive or impossible, CDB now supports the ability to map incoming values in a 3rd party data load to existing EDC data.

Enablement

The ability to map keys is automatically available.

Auto-increment Sequence Number

When importing 3rd party data into CDB, and the form or item group sequence number is not defined in the import manifest, CDB defaulted the Sequence Number to “1”. This can potentially cause issues when there are records where the Study, Site, Subject, Event, Form, Form Sequence Number, Item Group, and Item Group Sequence Number are the same. When those values are all the same, CDB is not able to uniquely identify rows, which can lead to a cartesian product in the CQL results, returning more rows than expected.

The cartesian product issue can be resolved by third party data vendors providing a Sequence Number for the form or item group, but this can be difficult to add in, and sometimes not possible. In those situations, CDB imports can now be configured to detect records that aren’t unique and automatically increment the form or item group Sequence Number during import.

In the manifest file, the rowid key has changed from taking an array as value to taking an object with two properties called groupid and distinctid. The input for the groupid key is an array of user-defined columns from the CSV file that can be used to group records together, in addition to the Study, Site, Subject, and Event. The input for the distinctid key is an array of user-defined columns from the CSV file that can uniquely identify records after the groups are defined.

When importing with a manifest file where rowid is an array (pre-21R3 configurations), Workbench now returns a warning in the log file to let the user know that rowid will eventually be deprecated, and that they should instead use groupid or distinctid.

Existing functionality with rowid is unchanged, and those imports will still be successful. The deprecation schedule is yet to be determined so customers will have ample time to make the necessary changes.

Use Case

The feature allows for the support for specific data formats to be imported into CDB without additional changes.

Enablement

This feature can be configured from the import package’s manifest file.

Role Management & Security

Features in this section are enhancements to the System Tools > Role Management and System Tools > Users areas, as well as changes to standard Study Roles, security, and access control in Vault CDMS.

Show Course Completion in the Training Report

When a user clicks Add Curriculum, Save to Study, or Save to Multiple Studies, Vault now populates the Courses associated with the Curriculum. Vault shows these Courses in the training report. When the Enrollment Reconciliation job runs, Vault populates the Course information in the Enrollment Completion object.

Use Case

These enhancements support regulatory compliance by preventing vault-wide and study-wide users from accessing Vault CDMS before completing the appropriate training and increasing the reporting ability on the training progress of users across Studies.

Enablement

For existing Studies to show the assigned Courses in the training report, a vault administrator needs to edit the lms.courseDrillDownEnabled study setting and set the value to “true”. For Studies created after this release, this feature is automatically enabled.

Feature Enablement Summary

Feature Name Configuration Dependencies Day 1 Impact to Primary Users Users with Day 1 Visibility
Data Entry
Empty Form Link Indicator Studio  
  • Study Designer
Unsetting ILB Restores Default Data    
  • Sites
Study Administration
Audit Trail Export by Site    
  • Study Designer
Audit Trail Export Filtering    
  • Study Designer
Extract Job Governor null  
  • Data Managers
  • Study-Administrators
Study Design & Configuration
Progressive Display Enhancements   Rules V2
  • Study Designer
  • Librarian
Vault CDB
CDB Views    
  • Data Manager
  • Lead Data Manager
Additional UI Filters for Listings    
  • Data Manager
  • Lead Data Manager
Ingestion Audit Log    
  • Data Manager
  • Lead Data Manager
Key Manager    
  • Data Manager
  • Lead Data Manager
Auto-increment Sequence Number Workbench  
  • Data Manager
  • Lead Data Manager
Role Management & Security
Show Course Completion in the Training Report Vault Admin Veeva Learning Integration
  • Lead Data Manager
  • User Administrator

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.