What's New in 23R3
Pre-Release Date: November 6, 2023 | CDB Pre-Release Date: November 13, 2023 | Release Date: November 17 & December 1, 2023We are pleased to bring you Vault CDMS in 23R3. Read about the new features below. You can find information on enabling new features in the 23R3 Feature Enablement Details. Information on developer features (REST API) is in the Developer Portal.
CDMS
Features in this section are changes that apply to all application areas of Vault CDMS.
Detail PDFS: Fast Web View
Use Case
This enhancement supports FDA compliance and reduces file sizes and file opening times, allowing users to view the file before it is completely downloaded.
Description
With this release, we’ve optimized the Detail PDF files generated in bulk for fast web view in order to align with FDA guidance for regulatory submissions. This update applies to the files generated in the Detail PDF job and Site Closeout PDFs
Enablement & Configuration
This feature is automatically enabled.
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.
ILB Enhancements
Use Case
These enhancements improve consistency and clarity for users marking forms as ILB or resetting forms. They also prevent forms and items from being linked to forms that are blank or that are marked as ILB.
Description
This feature includes the following changes to the Intentionally Left Blank functionality, which apply to standard and lab forms:
- The option to mark a form as Intentionally Left Blank will now be displayed as a button at the top of the form instead of an action in the action menu. In Lab forms, the button will replace the Lab Tests Not Performed checkbox.
- The ILB button will be disabled in cases when ILB is not allowed because the study or site is locked, the form is locked, frozen, or marked for removal, or there are existing item links.
- The task bar will include blank forms
These changes will affect form linking functionality accordingly:
- Forms marked as ILB cannot be included in form to form or item to form linking - marking a form as ILB after it has been linked will remove form links.
- When a linked form is reset, existing form links for that form will be removed.
- The Reset Form option will be disabled if there are existing item links.
Enablement & Configuration
This feature is automatically enabled in Studies using Form Linking V2 and Data Entry V2.
Learn More
Reports & Dashboards
The following are new features for reports and dashboards in Vault CDMS.
Standard Versions of CDMS Operational Reports
Use Case
Veeva can update standard reports without creating a new version, and organizations can use those reports as templates to create their own reports.
Description
With this release, CDMS operational reports (V3) are now available as Standard Vault Reports. This feature includes changes to filters, columns, type, name, and description. New standard reports are tagged with the Veeva report tag and marked as “created by the System.”
The previous versions of these reports, V1 and V2, were editable custom reports, which meant that when standard reports were edited, they would no longer be identical across all vaults. Because of this, providing updates and enhancements to these reports can be difficult. By standardizing report templates, we can easily make changes to these reports without creating a new version of the report.
If an organization requires changes to a standard report, they can use it as a template. They can copy the report and make their changes in the copy.
Note that the Label and Short Label columns will only be filled for Form Definitions created after the 23R3 release. These columns will be blank for already existing Form Definitions.
| Report | Report Type | Description |
|---|---|---|
| Event Progress Listing | Template: Event Progress Listing | Listing of all events and their progress in the study |
| Form Progress Listing | Template: Form Progress Listing | Listing of all forms and their progress in the study |
| Query Detail Listing | Template: Query Detail Listing | Detailed listing of all queries in the study |
| Standard Template: Casebook Signature Summary (V3) | Casebook Operational Summary with Site | A summary matrix report of signature status by Casebook. Possible values include Yes to indicate if a casebook is fully signed and No to indicate if a casebook is not signed. |
| Standard Template: Comprehensive Form Summary (V3) | Template: Form with Event, Form Def, Site, Subject, Form Summary | A tabular report detailing the form's SDV, DMR, Frozen, Signature and Locked statuses and the dates when those were completed, grouped by site and subject. Only includes submitted forms. |
| Standard Template: Cumulative Subject Creation per Week (V3) | Template: Subject | A summary matrix report of the number of subjects created per week, grouped by site. |
| Standard Template: Detailed Missing Forms Report (V3) | Template: Form with Event and Form Def, Site and Subject | A tabular report with of non-submitted forms that are overdue. Only includes forms that have been added to the schedule but are not yet submitted. Events must be configured with Overdue Days in order for forms at that event to be marked as overdue. |
| Standard Template: Event Signature Summary (V3) | Event with Study Site and Event Operational Summary | A summary matrix report counting the signature status submitted events. Possible values include Yes to indicate if an event is signed, No to indicate if an event was signed and was unsigned, or None to indicate if an event has never been signed. |
| Standard Template: Event Status (V3) | Template: Event with Event Operational Summary | A matrix report, filtered by study, providing a count of events by site and status. |
| Standard Template: Form Cycle Time Summary (V3) | Template: Form Cycle Time Summary | A tabular report of form cycle times, broken down by site. Cycle times include: Visit to Form Submit, Form Submit to SDV, DMR, Signature, Frozen and Lock |
| Standard Template: Form DMR Detail (V3) | Template: Form Operational Summary with Event and Form Definition | A tabular report of DMR status for forms where DMR is required, grouped by site and subject. Possible values include Yes to indicate if all required items on the form are DMR Complete or No to indicate if not all required items are DMR Complete. |
| Standard Template: Form DMR Monitoring Activity per Week (V3) | Template: Form Operational Summary with Form and Study Site | A summary matrix report of the number of forms marked as DMR Complete, per week. Sites are included when at least one form has been marked as DMR Complete. |
| Standard Template: Form DMR Summary (V3) | Template: Form Operational Summary with Form and Study Site | A summary matrix report of DMR status at the form level. Only includes forms where DMR is required. Possible values include Yes to indicate if all required items on the form are DMR Complete or No to indicate if not all required items are DMR Complete. |
| Standard Template: Form SDV Detail (V3) | Template: Form Operational Summary with Event and Form Definition | A tabular report of SDV status for forms where SDV is required, grouped by site and subject. Possible values include Yes to indicate if all required items on the form are SDV Complete or No to indicate if not all required items are SDV Complete. |
| Standard Template: Form SDV Monitoring Activity per Week (V3) | Template: Form Operational Summary with Form and Study Site | A summary matrix report of the number of forms marked as SDV Complete, per week. Sites are included when at least one form has been marked as SDV Complete. |
| Standard Template: Form SDV Summary (V3) | Template: Form Operational Summary with Form and Study Site | A summary matrix report of SDV status at the form level. Only includes forms where SDV is required. Possible values include Yes to indicate if all required items on the form are SDV Complete or No to indicate if not all required items are SDV Complete. |
| Standard Template: Form Signature Summary (V3) | Form with Study Site and Summary | A summary matrix report counting the signature status submitted forms. Possible values include Yes to indicate if a form is signed, No to indicate if a form was signed and was unsigned, or None to indicate if a form has never been signed. |
| Standard Template: Form Status (V3) | Template: Form with Event and Study Site and Subject | A summary matrix report of all form statuses, broken down by site and subject. |
| Standard Template: Frozen Casebook Summary (V3) | Casebook Operational Summary with Site | A summary matrix report of signature status by Casebook. Possible values include Yes to indicate if a casebook is fully frozen and No to indicate if a casebook is not frozen. |
| Standard Template: Frozen Event Summary (V3) | Event with Study Site and Event Operational Summary | A summary matrix report counting the freeze status of submitted events. Possible values include Yes to indicate if an event is frozen, No to indicate if an event was frozen and was unfrozen, or None to indicate if an event has never been frozen. |
| Standard Template: Frozen Form Summary (V3) | Form with Study Site and Summary | A summary matrix report counting the freeze status of submitted forms. Possible values include Yes to indicate if a form is frozen, No to indicate if a form was frozen and was unfrozen, or None to indicate if a form has never been frozen. |
| Standard Template: JDrug Coding Report (V3) | Template: Clinical Coding | Clinical Coding Request and assigned codes (if assigned) for JDrug based forms; Standard Reports are updated by Veeva |
| Standard Template: Locked Casebook Summary (V3) | Casebook Operational Summary with Site | A summary matrix report of signature status by Casebook. Possible values include Yes to indicate if a casebook is fully locked and No to indicate if a casebook is not locked. |
| Standard Template: Locked Event Summary (V3) | Event with Study Site and Event Operational Summary | A summary matrix report counting the lock status of submitted events. Possible values include Yes to indicate if an event is locked, No to indicate if an event was locked and was unlocked, or None to indicate if an event has never been locked. |
| Standard Template: Locked Form Summary (V3) | Form with Study Site and Summary | A summary matrix report counting the lock status of submitted forms. Possible values include Yes to indicate if a form is locked, No to indicate if a form was locked and was unlocked, or None to indicate if a form has never been locked. |
| Standard Template: MedDRA Coding Report (V3) | Template: Clinical Coding | Clinical Coding Request and assigned codes (if assigned) for MedDRA and MedDRAJ based forms; Standard Reports are updated by Veeva |
| Standard Template: Overdue Form Entry per Event (V3) | Template: Event with Event Definition and Event Summary | A tabular report of blank and in progress events, grouped by site and subject. Includes the expected number of forms at each event and the number of days data entry is overdue. Only include events that are configured with an overdue days value. |
| Standard Template: Queries Causing Data Value Change (V3) | Query Operational Summary with Query | A tabular report of system queries that caused the item value to change, grouped by study and query rule. |
| Standard Template: Query Aging by Site (V3) | Template: Query Cycle Time Summary | A summary matrix report of the open and answered query counts by query age grouping (1 Week, 2 Week, 3 Week, 4 Week, >4 Weeks), grouped by site. |
| Standard Template: Query Cycle Time Summary (V3) | Template: Query Cycle Time Summary | A tabular report of all queries in a study. Cycle times include Query Age, Time to First Response and Time from Open to Closed. |
| Standard Template: Query Details by Site and Subject (V3) | Template: Query with Subject and Query Binding and Query Message | A tabular report of query details, grouped by site and subject. |
| Standard Template: Query Volume by Rule Definition (V3) | Template: Rule Definition with Study and Query Binding | A summary matrix report of the number of queries per rule definition, grouped by site. |
| Standard Template: Query Volume per Form (V3) | Template: Form with Form Definition and Query Binding | A summary matrix report of the number of queries per form definition. |
| Standard Template: Query Volume per Week by Site (V3) | Template: Study Site with Query Binding | A summary matrix report of the number of queries created per week, grouped by site. |
| Standard Template: Safety Cases (V3) | Template: Safety | A tabular report of safety cases in a study. |
| Standard Template: Schedule Deviation Report (V3) | Template: Event Operational Summary with Event Definition | A tabular report of events, showing adherence to the planned visit schedule, grouped by site and subject. |
| Standard Template: Site Queries (V3) | Template: Query Binding with Study Site | A summary matrix report of the number of queries, grouped by query status and site. |
| Standard Template: Study Closeout Status (V3) | Template: Study Closeout | A tabular report of the closeout status of each site in a study. |
| Standard Template: Subject Status Summary by Site (V3) | Template: Subject with Study and Study Site | A summary matrix report counting the number of subjects in each status, grouped by site. |
| Standard Template: Subject Study Progression (V3) | Template: Event Operational Summary | A tabular report of planned and entered events, grouped by site and subject. |
| Standard Template: Unique CRF Listing (V3) | Template: Form Definition | A tabular report of unique CRF definitions in a study. |
| Standard Template: Unique Rule Definition Listing (V3) | Template: Rule Definition with Study and Query Binding | A tabular report of unique rule definitions. |
| Standard Template: WHODrug Coding Report (V3) | Template: Clinical Coding | Clinical Coding Request and assigned codes (if assigned) for WHODrug based forms; Standard Reports are updated by Veeva |
| Subject Progress Listing | Template: Subject Progress Listing | Listing of all subjects and their progress in the study |
Enablement & Configuration
These reports and the dashboard are automatically available, but a Vault Owner must update the sharing settings for the reports to be visible to other users.
Standard Coding Reports & Dashboard
Use Case
These reports and the dashboard provide coders with reports in a standard format, which can help coders make coding decisions and track required coding metrics. Through Standard Veeva Reports, we can now issue updates directly to the reports, which isn’t possible with custom reports.
Description
With this release, coding reports are available in the Veeva Standard Report format. All CDMS vaults (new and existing) will have the following standard reports:
- MedDRA Standard Report V3 (supports MedDRA and MedDRAJ)
- WHODrug Standard Report V3 (supports both B3 and C3)
- JDrug Standard Report
This feature also makes available the Coder Dashboard V3 dashboard, which includes the following components:
- Coding Statuses
- Pending Coding
- Percent Coded vs. Autocoded
- Query Statuses
- Pending Queries
- Query by Site
If all features are enabled in Coder Tools, the standard reports for all dictionaries will include all of the relevant columns for those features. Because these reports are Veeva Standard Reports, users can’t customize them. Instead, a user can copy the report and make their changes in the copy. For example, an organization may want to remove the Preferred Base column from the WHODrug Standard Report V3.
Enablement & Configuration
These reports and the dashboard are automatically available, but a Vault Owner must update the sharing settings for the reports to be visible to other users.
Route Coding Reports to Coder
Use Case
Coders can access a Code Request, a specific Query, Note, Property, or Group on the Code Requests page by clicking the link in the Name column of coding reports. This helps coders take quick actions on Code Requests.
Description
Links for the Name columns in Vault Coding reports now lead directly to the related Code Request pages in Vault Coder. Links in the Name column of Coding Reports have the format VV-XXXX., When routed to the respective Code Request page, the page is filtered for that specific Code Request record. A new filter for Name will be displayed and has been added to the Code Request page. If the Name link for a coding query, coding note, or coding property is clicked then that will be in focus on the Code Request page. The same applies to when the Name link is clicked for a Grouped Code Request. If the Name link for a Medical Coding Item Definition is clicked, then the respective Code Request page will load showing all the respective Coding Requests. A name filter on the Code Request Page can be removed at any time by the Coder.
Enablement & Configuration
This change applies automatically inany re3ports that reference coding objects.
Study Design & Configuration
Features in this area apply to Studio, the study design and configuration area for Vault EDC.
Rules: Usability Improvements
Use Case
These enhancements provide improved rule capabilities and execution.
Description
This release includes the following updates to improve rule usability:
@PreviousEventidentifiers can now be used with Set Derived Value rules- We’ve updated how rules are evaluated when they contain multiple Item to Form links (such as from a repeating Item Group, for example) and Item to Form links to the same Form. Previously, the link identifiers were grouped at the Form level and evaluated once. With this release, individual link identifiers will be evaluated separately to ensure that linked information from a specific Item Group is correctly associated in rule processing.
- Vault will no longer prevent users from submitting a form when submission would result in a query being opened on a locked object (Form, Event). With this release, Vault will allow form submission but skip opening a query on a locked object.
Enablement & Configuration
This improvements are automatically applied.
Study Administration
Features in this section apply to EDC Tools, a study-level administration area for Vault EDC.
Clinical Data Change Extract
Use Case
This feature provides users with a formatted data extract that is easy to consume when additional monitoring may be required due to frequent data changes.
Description
This feature includes a new job in EDC Tools called the Data Change Extract, where users with the Manage Jobs permission can view changes made to Item and Event Date data during a specific time period. Users can include up to 90 days of data in the extract and specify which forms to include. The extract can be run on ad-hoc or scheduled on a daily, weekly, or monthly basis. The extract is separated into columns so that changes are easily identifiable. Users can also send the extract to an FTP folder.
The Data Change Extract will only include changes to data that occur after the 23R3 release. When testing this feature in pre-release or non-production vaults, Veeva recommends creating a new test study or deleting the old test data and creating new subjects before running the job. If there is existing data and configuration changes are made, the job may not successfully complete.
Enablement & Configuration
This feature is automatically available.
Learn More
Date of First Review
Use Case
This update improves cycle time metric reporting by differentiating between the initial and most recent SDV/DMR date in cases where SDV/DMR is updated due to study or data changes.
Description
With this release, the date of the first SDV and DMR review for an Item or Event Date will display as columns in the Form Operational Summary report, Form Progress Listing, Event Progress Listing, and the SYS_FORM dataset in the Study Data Extract job.
Enablement & Configuration
This change applies to all new studies created after the 23R3 release.
Date of First Submission
Use Case
This feature can be used to calculate cycle times, such as the time from form creation to first submit or the time from first submit to lock, etc.
Description
For studies created after 23R3, the system will track the date that a form is first submitted in the Form Progress Listing job, Core Listings, and Study Data Extracts. Once set, the date won’t be cleared unless the form is reset. The Date of First Submission doesn’t change if the form is submitted multiple times.
See below for details about the impact of this feature:
- Form Progress Listings:
- Added First Submission Date and Latest Submission Date columns
- Study Data Extracts(23R3 Version):
- Added First Submission Date (FIRSTSUBMITDT) and Last Submission Date (LASTSUBMITDT) columns to the SYS_FORM dataset
- Added First Submission Date (FIRSTSUBMITDT) column to Clinical Datasets and updated the SUBMITDT column to LASTSUBMITDT
- Core Listings:
- Added Form First Submission Date column and renamed the Form Submission Date column to Form Last Submission Date
Enablement & Configuration
This change applies to all new studies created after the 23R3 release.
EDC General Enhancements
Use Case
These updates improve usability and user experience.
Description
We’ve made the following enhancements to EDC:
- Snapshots: We’ve removed the refresh/sync icon from the snapshots results page. Users should refresh their browser to view updated results.
- Small Screen Size Warning: We’ve updated the warning message window to more prominently guide the user. The “Test My Setup” option has been relabeled “Help Me Fix It” and is the primary action.
- Prior to this release, Vault only showed repeating forms in the Review UI when data was present. With this release, the Review UI display will match the Data Entry display. An empty form icon will display, along with an indicator that no form instances exist. When selected, the form name will show in the right panel with an indication that there are no records to display.
Enablement & Configuration
These updates apply automatically.
Import & Export Training Mapping
Use Case
This feature helps support operational processes for revising training mappings where importing is preferred. For CROs who manage multiple sponsor vaults, the import capability alleviates the need to re-create the individual mappings in each new sponsor vault.
Description
Vault now supports the import and export of training mappings for the Veeva Learning Integration. This allows organizations to easily copy curriculum assignments from one vault to another.
This feature introduces two new actions: Load from File and Export to File.
The Export to File action generates an Excel™ file (“StudyName_LearningSystemName_Timestamp.xlsx”) of the current curriculum assignment grid.
Users can edit that file and then use the Load from File action to import it into the current study or another study to use those mappings. Import supports both CSV and XLSX file formats.
As part of this feature, we made the following UI changes:
- We moved the Edit and Copy from Study actions from buttons into the new Actions menu.
- After the initial add of curriculums, the button is now lableled Sync Curriculum.
Enablement & Configuration
This feature is automatically enabled. The curriculum itself must be added first before import of training mapping is allowed.
Fire Query when ILB Setting
Use Case
Studies have required critical data points that, in most cases, shouldn’t be left blank. This feature automatically generates a query when data is marked as ILB by Site users in order to verify that the data was marked correctly.
Description
With this feature, users in Studio have the option to choose whether or not a required item can be set to Intentionally Left Blank (ILB). Sites will receive a query in Data Entry when selecting ILB on items that are configured with this setting. The SDS has been updated to include this setting which will appear on the Excel-formatted specification and annotated CRF.
Enablement & Configuration
This feature can be enabled in the Study Configuration and is available for new and existing studies. Apply to existing studies by deploying the updated item settings.
Labs: Import Lab Units and Codelists
Use Case
This feature allows users to save time by importing multiple units and codelists at once instead of adding each unit or codelist individually. Users can also easily move Lab Units and Codelists between non-connected Vaults by exporting from one Vault and importing into another Vault.
Description
Lab Data Managers can now import multiple Lab Units and Codelists at once. Like importing Analytes, importing Units and Codelists will be validated by the system and Vault will display feedback on what records need attention. Once the file is fully validated, the file can be imported. Users can export Units and Codelists in CSV format or as an Excel™ file.
Enablement & Configuration
Auto-on with the 23R3 general release.
Learn More
Study Priority and Job Governor Enhancements
Use Case
These updates improve usability.
Description
We’ve made the following enhancements regarding extract job governance and study priority:
- Job Governor:
- Users can’t start an ad hoc Unique Terms Report if one is already queued or in progress
- Users can’t schedule more than two Audit Trail Export jobs at once per study
- Study Priority:
- Users can set an expiration date when setting study priority. The default value is 7 days from the current date
- Priority expiration will be reset to 7 days after a priority study is locked
Enablement & Configuration
This enhancements are automatically available.
Review Plan Assignment V3 Enhancements
Use Case
This feature provides more clarity when assigning Review Plans and using the Reevaluate Plan Assignment job and additional options to further meet configuration requirements with targeted SDV and DMR Review Plans.
Description
This feature includes the following new option in the Assignment Criteria section when creating a Review Plan Assignment: “Apply Review Plan Assignment to all sites within selected countries individually.” This setting will respect the assigned ordinals and percentages individually for each site within the selected country.
In addition, the Reorder Assignment job has been renamed to Reevaluate Plan Assignment for clarity, as the job runs through the history of each subject and applies Review Plans based on the current/updated criteria. A downloadable report and log file are provided in the Job History tab that detail the subjects whose review plans were changed as a result of the job. Options to select Specific Sites and Preview the job’s output are also available with this release.
Enablement & Configuration
Auto-on with the 23R3 general release.
Study Data Extract Enhancements
Use Case
These updates provide greater detail to the user and improve usability of the Study Data Extract job.
Description
We’ve made the following changes to Study Data Extracts:
- SDE Sent to CDB: Starting with this release, users can only include SYS datasets and Custom Objects when sending SDE data to CDB. The option to include clinical datasets is disabled. This applies to both the 23R2 and 23R3 versions of the SDE.
- SAS enhancements: With this release, we’ve increased the compression for SDE jobs being exported as an SAS file to minimize processing time, and we’ve changed the way XPT files are generated so that they can be opened with the SAS Universal Viewer. This applies to all SDE versions.
- The 23R3 version of the SDE includes the following changes:
- Clinical Datasets now include columns for Date of First Submission (FIRSTSUBMITDT), Form Created Date (CREATEDT), and Form (Latest) Submission Date (LASTSUBMITDT)
- The column header for the Last Submit Date column in SYS_FORM dataset has been changed from SUBMITDT to LASTSUBMITDT for consistency.
- The SYS_SUB dataset will include columns for Latest Arm (LATESTARM), Latest Cohort (LATESTCOHORT), and Latest Substudy (LATESTSUBSTUDY) if the study includes these subject group definitions.
- The SYS_PD dataset has been updated with four new columns:
- Protocol Deviation Restricted (RESTRICTED): visible only when the user selects the Include Restricted Data option
- Event External ID (EVENTEID)
- Form External ID (FORMEID)
- Item Group External ID (IGROUPEID)
- Item Group External ID (IGROUPEID) has been added to the following datasets:
- SYS_LINKS (if Item to Form Linking is enabled)
- SYS_ILB
- SYS_Q
- Clinical Lab datasets
- The SYS_ASM and SYS_ASMR datasets have been updated to include the following new columns:
- Event Group (EGROUP)
- Event Group Definition (EGROUPDEF)
- Event Group External ID (EGROUPEID
- Event (EVENT)
- Event Definition (EVENTDEF)
- Event External ID (EVENTEID)
- Event Group Sequence (ESEQ)
- Form (SOURCEF)
- Form Definition (SOURCEFDEF)
- Form External ID (SOURCEFEID)
- Form Sequence (FSEQ)
- The SYS_ASMR dataset includes the following columns in addition to the columns listed above:
- Question Number (QUESNUM)
- Question External ID (QUESEID)
- For studies using a Safety configuration, the 23R3 version of the SDE includes 2 new SYS datasets for Safety Cases (SYS_SAFEC) and Safety Messages (SYS_SAFM)
Enablement & Configuration
These updates are available immediately upon release and are limited to the 23R3 version of the SDE unless indicated otherwise.
Form Progress Listing: SDV & DMR Re-review Columns
Use Case
Differentiating between forms that require SDV/DMR for the first time and forms that require re-review due to configuration or data changes increases clarity of reporting and metrics.
Description
With this release, the Form Progress Listing identifies when a form that has been previously reviewed (SDV/DMR) requires re-review. The CSV output for this listing now includes Requires Re-SDV and Requires Re-DMR columns. If the Date of First SDV/DMR field is populated but the Date of Latest SDV/DMR field is blank, the Requires Re-SDV/Re-DMR columns will be marked with “Yes.” Conversely, if both the Date of First SDV/DMR and Date of Latest SDV/DMR fields are populated, the Requires Re-SDV/Re-DMR columns will be marked with “No”.
Enablement & Configuration
New columns are automatically included in the Form Progress Listing upon release, but will be blank for studies that were created prior to the 23R3 release.
Study Progress Listings Enhancements
Use Case
These changes provide consistency with other query reporting and add support for Data Model 1 studies.
Description
This release includes the following Study Progress Listing job enhancements:
- Query Detail Listing: Renamed the Created Date column to Query Created Date, and the Created By column to Query Created By
- Form Progress Listing: Updated the SDV Required and DMR Required fields to support Data Model 1 studies when the Form Progress Listing is sent to Vault Reports
Enablement & Configuration
These changes apply automatically.
Frozen Forms Support for Amendments
Use Case
This enhancement provides more control on how the system manages frozen data when running a retrospective amendment. Data Managers no longer have to manually unfreeze the casebook data in order to apply the amendment. This enhancement is intended for retrospective amendments that include destructive changes.
Description
When performing a retrospective amendment, Vault will automatically retain the frozen status on unimpacted data and will unfreeze data as appropriate where there are changes to the forms. After the retrospective amendment is applied:
- Unit/Codelist Item: when labels change, the Codelist Item is not unfrozen when the change is applied to the frozen Codelist Items
- Item: when Type, Label, Short Label, or Hint Labels are changed, the Item is unfrozen if there is a change to the Item
- Item Group: when Override Label or Short Label are changed, the Item Group is unfrozen if there is a change to the Item Group
- Form: when Form properties change (e.g., form label or description), the Form is not unfrozen when the change is applied to the frozen Form
- Event: when a form is added or removed from an Event, the Event is not unfrozen when the change applies to the frozen Event
- Casebooks: when a Casebook is frozen and there is a change to the subject, the Casebook is not unfrozen when the change applies to the frozen Casebook
- New Items, Item Groups, Forms, and Events added will be added in an unfrozen state (New Item Groups added will have all of the items added in an unfrozen state)
Enablement & Configuration
Contact Veeva Support to enable this feature in your vault. This is an update for studies operating in Data Model 2. Studies in Data Model 1 had already operated in this manner and will remain the same, as described above for retrospective amendments. Note that Veeva will only enable this feature when there is a retrospective amendment with destructive changes.
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.
Roles, Permissions & Security Enhancements
Description
To support new features in the 23R3 release, we made the following changes:
New Study Roles:
- CDB API Read Write: This role allows for an API user to interact with CDB to open, answer, and close queries from both EDC and third party data sources.
Updates to existing Study Roles:
- Added the Manage Email Group Assignment permission to the CDMS API Read Write role
- Assigned the following permissions to the CDMS API Read Only and CDMS API Read Write roles:
- View Library
- View Study Design
- View Classification
- Assigned the following permissions to the CDMS API Read Write role:
- Design Library
- Design Study
- Edit Classification
- Assigned the Manage Jobs permission to the CDMS Safety Administrator role
New dependencies:
- The Manage Safety Integrations permission now requires the Manage Jobs permission.
Enablement & Configuration
These changes apply automatically to all CDMS standard Study Roles. If an organization uses custom Study Roles, a user administrator must update their Study Roles after the release to use these permissions.
VeevaID Support
Use Case
This feature provides support for linking existing VeevaID users with new or updated CDMS users. It primarily benefits site users who already have a VeevaID to reduce the number of separate logins the user has for different sponsor’s studies and Veeva products. This feature also supports user administrators with managing existing accounts.
Description
When adding new Users to a vault, Vault can now check the user’s email to confirm if the account belongs to an existing user with a VeevaID. When the user already has a valid VeevaID, Vault adds the user to the vault as a cross-domain user with their VeevaID security policy.
Once a VeevaID user is created, they are a cross-domain user, and so you can only make changes to User Name, Study Role, Site Access, and Country Access.
In support of this feature, we added a new, optional column to the user import template, Bypass VeevaID Check. By default, this is set to “No”. When this column is set to “Yes”, Vault skips the VeevaID verification and instead creates the user strictly based on the provided User Name. This is useful when a user needs separate accounts for user acceptance testing where VeevaID may not be desired.
Enablement & Configuration
Contact Veeva Support to discuss this feature.
Integrations
Features in this section are new integrations with Vault CDMS or enhancements to existing integrations.
Safety Configuration Moved to Studio
Use Case
Hosting the Safety Integration configurations in Studio will allow the application of the EDC library and deployment capabilities onto the Safety Integration. The new Form Configuration wizard supports the Safety to EDC form item mappings, but also provides enhanced options for multiple mappings for each Safety Form Type as well as new Inclusion Criteria for Study Drugs into a safety case.
Description
With this release, we moved all Safety Integration configurations from EDC Tools to Studio.
Study settings are now extended by Safety Integration Type. The available types are E2B - Vault Safety, for integration with the Vault Safety application, and E2B - External for external safety systems.
Users can configure their study-specific Safety Settings and Form Configurations from the new Safety Configuration area of Studio. Form Configurations are now performed in a wizard, which guides users through the mapping of safety form types to EDC forms and their respective items, and thereafter the selection of inclusion criteria into the safety case.
While the Integration Setup and Job Scheduler are shown under the Safety Settings, they are configured in Tools > Safety Integrations > Safety Settings as these settings differ by environment and are not deployed.
As part of this feature, additional capabilities for the CDMS Safety Integrations are now in place:
- The Safety Case Inclusion Criteria for Study Drugs have been enhanced to allow the selection of the first dispense date as well as closest on/before and closest on/after the SAE start date to be included.
- Each Safety Form Type can now be mapped to multiple EDC forms.
- Entries in a Safety Case can now also be from repeating item groups, not just forms across all Safety Form Types
- The driving Safety Key Item of SAE and Study Drug dispense forms can be configured with either a defined value or now alternatively ‘Any non empty value’. This allows e.g. for configuring a dispense form to be a candidate to be in the Safety Case simply by a non-empty Start Date.
- The NullFlavors for coded fields have been amended with the ‘10067482’ code.
Enablement & Configuration
This feature is automatically enabled.
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 Listing Builder
Use Case
CDB Listing Builder enables data managers to build listings by pulling data from multiple Sources and Forms using an intuitive drag and drop user interface. Selecting the row structure enables the end user to choose whether or not to align the data dependent or independent of the study schedule. Defining the column structure enables the user to combine data from different sources into stacked columns lending to a more narrow, readable Listing.
Description
Users with permission can now create and save simple Listings, Checks, or Views without needing to know CQL. They can select Forms and Items to include in the listing, as well as certain Study and Item properties.
Users can define the row structure of a listing by either of the following options:
- By Subject: This option attempts to display data from multiple forms across events in a single row for the subject, and displays all data where subjects match across events. Any selected schedule-related fields, such as Event Date or Event Name are set to null in the listing.
- By Schedule: This option displays form data from different events on separate rows. We recommend this option if schedule-related fields are required.
The column structure of a listing can be defined by either of the following options:
- Wide (Side by Site): Each column displays a single unique item or item property.
- Stacked (Union): Each column can contain multiple items or item properties from different forms stacked together. A user can include up to five (5) items and/or item properties per column.
For any unmodified listing created via the Listing Builder, users can open the listing in the Listing Builder to edit.
Enablement & Configuration
This feature is automatically available. Users with permission to create listings, checks, or views can use the Listing Builder to do so.
Migration Vault
Features in this section are new features for Migration Vault.
Retrying TAPIs & Runs
Use Case
Prior to this feature, once a connection was lost or a read timeout occurred, it could not be retried. In non-production environments, this required study data to be deleted and remigrated, which is not applicable to production environments. While this feature doesn’t eliminate the need to delete study data in production environments, it will help mitigate certain issues that require a Migration Reset. Migration Resets should be the last resort.
Description
This feature retries connection-related errors, such as client-side connection issues and read timeouts. Previously, since there were no retries, connection-related errors required a remigration. Now Migrations engineers can retry the Run, Med Coding, and Post-Run steps for loads should they fail in certain situations.
Enablement & Configuration
For retrying TAPIs, this feature is automatically enabled. For Retrying Runs, assistance from a Migration engineer is required.
EDC Duplicate Detection Job
Use Case
Migration engineers can run the Duplicate Detection Job after a migration recovery and share the results with stakeholders. The results can then be analyzed to provide details on next steps. The job report provides one of three results:
- No duplicates found: recovery a success, proceed as normal
- Manageable amount of duplicates found: manual subject deletion in EDC required
- Too many duplicates found: Migration Reset required
Description
This feature helps Migration engineers find duplicate objects created during the recovery process of a failed production run. Duplicate Detection Job results are generated in batches of CSVs and shared with Migration stakeholders.
Enablement & Configuration
Migration engineers must run this job.
Separating Form Submission from Post-Run Step
Use Case
Form Submissions were previously included within the Post-Run step. When separated, forms can be submitted before applying attributes. This helps avoid concurrent, asynchronous jobs and provides more consistency across loads, preventing notable variations in _Post-Run _times.
Description
This feature separates Form Submissions, making it a distinct step within the Workflow Progress table. Previously, it was included within the Post-Run step.
Enablement & Configuration
This feature is automatically enabled.
Migration Report & Log File Enhancements
Use Case
This enhancement provides users with more information on migrated Studies, which can be used to help troubleshoot errors and plan for future migrations.
Description
This feature enhances the existing Migration Report by improving the way errors appear in Log Files, such as log time for the entire load and each workflow step. Users now have more insight into how long each step or load takes based on Study size.
Enablement & Configuration
This feature is automatically enabled.
Setting Subject Statuses
Use Case
The system now automates the setting of Subject Statuses so users no longer have to manually run status rules in multiple batches.
Description
With this release, the system will automate the setting of Subject Statuses as part of the Workflow Progress table. The setting of Subject Statuses can be initiated by using the Execute or Execute All Steps feature.
When the Execute All Steps feature is used, Subject Statuses are only set if the previous step is a success. If the previous step fails, the Subject Statuses step does not auto-start. The step is also optional and can be skipped.
In Migration Vault, Subject Status rules are executed in the following order:
- Pre Screen
- Consented
- In Screening
- Screen Failure
- Enrolled
- Randomized
- Started Treatment
- End of Treatment
- Withdrawn
- Started Follow Up
- Lost to Follow Up
- Complete
Enablement & Configuration
This feature is automatically enabled. Users must implement the default CDMS Subject Status execution order.
Skipping a Step during Execute All & Rewording Stop Link
Use Case
The skipping enhancement supports execution automation and reduces manual effort for users who need to skip a workflow step. The rewording of the Stop link improves the user experience by clarifying the actions taken by the user, whether stopping a step or stopping the workflow.
Description
Previously, users could not skip individual Workflow Progress steps when using the Execute All Steps feature. If a specific step needed to be skipped, the feature could not be utilized. Now, users can skip optional steps when using this feature.
The Stop link in the Workflow Progress table now reflects the actions taken by the user. If a user chooses to stop the Execute All Steps workflow, they’ll see the new Stop Step option, which reflects the user’s ability to stop steps individually. Previously, the only option was Stop, which didn’t distinguish between stopping a step and stopping the entire workflow.
Enablement & Configuration
This feature is automatically enabled but users must select the steps they want to skip prior to executing a load.