New Features in 25R2 Limited Releases

25R2 Planned General Availability: July 25 & August 1, 2025

25R1.4 Release Date: June 20, 2025

25R1.3 Release Date: May 30, 2025

25R1.2 Release Date: April 25, 2025

We are pleased to bring you new functionality with each limited release. These release notes are updated with upcoming new features one week before the limited release date.

Enablement Changes: The enablement of each feature is subject to change from release to release. For limited releases in the same general release, we will update this page. Enablement may also change before the general release. Refer to the Release Impact Assessment for the most up to date enablement for a general release.

Clinical Data

Features in this section are changes that apply to all application areas of Veeva Clinical Data.

Include Deleted Data in PDFs 25R1.3

Use Case

To further clarify data revisions in the audit trail seen directly within the PDFs, the appendix now includes cases where data are removed.

Description

When generating closeout PDFs or running the Detail PDFs job, if a lead data manager chooses to include the audit trail, data that was removed by sites or a retrospective amendment will be included in the new Appendix section of the PDFs, “Deleted Data Audit Trail”. Bookmarks in the PDF follow the same order as the casebook schedule for easy navigation to the new section.

The following cases are included in the deleted data.

Retrospective amendment with destructive design changes
Site reset an event or form which was marked for removal
Site reset a repeating event
Site removed row in a repeating item group
Site removed the form linking by deleting a linked form
Query deletions, undo action in Quick Queries
Unscheduled Event is deleted

Restricted Data

Only users with access to restricted forms (users whose study role grants the Restricted Data Access permission) will see the Deleted Data Audit Trail. If the user who generated the file doesn’t have restricted data access, and there are deletions of restricted data, then Vault includes a note at the end of the PDF:

Note: The Deleted Data Audit Trail was not included in this file because the user who generated it did not have restricted data access. To include this data, please generate the file again as a user with restricted data access.

Enablement & Configuration

This feature is automatically enabled with the release.

Clinical Data Naming Update in PDF Export 25R1.2

Use Case

For clarity and simplicity, we have updated the name of the system to Veeva Clinical Data.

Description

This release updates PDF exports in the Clinical Data system to reflect the name change.

Enablement & Configuration

This feature is automatically enabled with the release.

Screen Size Warning Adjustment 25R1.2

Use Case

This update reduces the occurrences of the screen size warning dialog displaying to end users to provide a better UI/UX experience.

Description

The threshold has been lowered for triggering display of the screen size and resolution warning dialog, which will now display to users for screen widths < 1270 or heights < 550. The warning is now displayed when the application becomes unusable rather than when it’s sized below the recommended screen size.

Enablement & Configuration

This update applies automatically.

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.

Edit Value Button Hidden for Answered Queries 25R1.2

Use Case

This update changes the query dialog to help site users easily identify queries that have already been answered.

Description

When a query is in an answered state, the Edit Value button will now be hidden. Note, the user will still be able to edit the value where the query is shown by clicking the Edit Form button. Similarly per the existing behavior, when the query is in an Open state, the Edit Value button will be enabled.

Enablement & Configuration

This update is automatically available.

Quick Queries 25R1.3

Use Case

Sites and CRAs can eliminate the need to manually type out query messages and replies when using Quick Queries. Site users and monitors frequently use similar messages when opening and replying to queries, using text such as “Please confirm”, “Please verify”, etc. Sites will often reply with “The data is correct”, “Data updated” and “Marked as blank” or something similar. Quick Queries provides a clean, simple, and automated way for sites and CRAs to provide standard query messages and replies, drastically reducing the keystrokes required from users when creating queries, updating data, and answering queries.

Description

Standard query messages and responses provide a faster and better experience for Sites and CRAs. While opening manual queries, replying to manual queries, or replying to item property queries (edit checks) configured in Studio, the standardized options are made available based on the state of the data being entered or missing. Quick queries can be applied to data items and events.

CRAs are able to observe and record the source value within the query, which is easily referenced to compare and close the query after the site updates the data. Sites will not see the source value that the CRA included in the query, as it is only viewable within the Review tab and the audit trail if the user has the observed source value permission.

The available query messages and site responses will automate based on whether the item has a value or not. When opening a manual query, CRAs have three standard one-click options:

Check Value Against Source (available when data is present)
Enter Missing Value (available when data is missing)
Create Custom Query

Site users will have the following one-click options to select for item queries:

Edit Value
Mark Intentionally Blank (when data is missing)
Confirm Value is Correct (available when data is present)
Reply with Comment

Similar options are available to site users for event queries:

Enter Event Details
Edit Event Details
Mark as Did Not Occur (when data is missing)
Confirm Value is Correct (available when data is present)
Reply with Comment

The Create Custom Query and Reply with Comment options provide the CRAs and sites the option to manually type query messages and answers when needed.

When the site selects Edit Value, they must provide a reason for change. When this occurs, the system immediately puts the form to In Edit. The query will automatically be answered with the reply [Data updated] if the site user edits the value in the queried item or event.

Standard Query Messages for 25R2

System queries answered using Quick Queries will auto close when the conditions are no longer true, indicated with [Closed]. Quick query messages are seen with brackets around the text [ ] both in the UI and within the extracts.

Permissions

Quick Queries adds two new permissions to the following standard roles. These permissions are only effective when the study is using Quick Queries.

Edit Observed Source Value
CDMS Clinical Research Associate
CDMS Super User
View Observed Source Value
CDMS Clinical Research Associate
CDMS Super User
CDMS Data Manager
CDMS Lead Data Manager

Extracts & Listing Updates

The following new columns have been added to the Query Details Listing: Value Confirmed (Yes/No) and Observed Source Value. When using Quick Queries, the message text will appear in the Original Query Text, Latest Query Comment, and Latest Query Answer Text columns. Within the SDE, the following new columns have been added: Observed Source Value (OBSSOURCEVAL) and Quick Action Type (QUICKACTTYPE). The auto responses will appear in the system extracts as follows.

SYS_Q and SYS_QT:
- QTEXT
- QTEXTBASE
- QTEXTENG

Enablement & Configuration

Available for new studies where Query Teams is also enabled. To use Quick Queries, studies also require Query Teams. Sites must be part of the Site Team and CRAs must be part of the Clinical Team. For existing studies, the Study Setting can be revised and deployed.

Translations for “Subject Already Exists” Error 25R1.3

Use Case

The use of study language settings help convey to site users why a subject cannot be entered.

Description

With this feature, the system-provided error message seen in Data Entry for “Subject Already Exists” will be translated to the selected study language when the Study Language study setting is enabled for the study. If the Study Language setting is not enabled, then the message will default to the user’s language.

Enablement & Configuration

This update is automatically enabled.

Data Review

Features in this section are changes to the Review tab, a working area for clinical research associates and data managers, or to review functionality within the Data Entry tab.

Updates to Form Summary Fields 25R1.2

Use Case

This update ensures consistency across all cycle time calculations and supports reporting on cycle time metrics in Workbench and Clinical Reporting.

Description

The following Form Summary Cycle Time metrics will now return null values if the cycle time calculation is negative:

Update Visit to Form Submit Cycle Time
Update Submit to Signature Cycle Time
Update Submit to SDV Cycle Time
Update Submit to DMR Cycle Time
Update Submit to Frozen Cycle Time
Update Submit to Locked Cycle Time

In addition, the calculation for the Submit to Signature Cycle Time metric has been updated to use two decimal places.

Enablement & Configuration

This update is automatically available.

Clinical Coding

The following are new features for Veeva Coder, the clinical coding area for Veeva Coder.

Option to Include Autocoding for Approval 25R1.2

Use Case

In order to support coding consistency and the accuracy of review in Veeva Coder, when the approval workflow is enabled for a Study, Coder Administrators can now configure Autocoded terms to also go through the approval workflow. This update removes the need to rely on reports or extracts to perform these reviews externally.

Description

This feature adds a new Coder Tools Study/Default Study setting to Include Autocoding in Approval Workflow, which is enabled only when the existing setting Enable Approval Workflow is set to Yes.

This setting can be implemented as a Default Study Setting or individual Study Setting. When set to Yes, any terms that are autocoded due to a Synonym List or exact dictionary match will move to the Pending Approval status, and upon approval will move to a final status of Autocoded. The default value for this setting is No.
To support this addition of this field to the UI and provide more clarity to user administrators, we’ve also reorganized the settings layout and added additional tooltips. Tooltips are visible when hovering over the options while in Edit mode.

Enablement & Configuration

These updates are automatically available after the release. Existing and new studies will have a default vault of “No” for the “Include Autocoding in Approval Workflow” setting.

Sync Coder Lists Enhancements 25R1.3

Use Case

This update supports improved synonym list maintenance for customers managing studies across multiple production vaults using the EDC Sync Coding Lists Vault connection.

Description

Prior to this release, customers with multiple PROD vaults using the EDC Sync Coding Lists Vault connection could only use the options to Apply to Synonym List when approving or rejecting a code and the Propagate Code function in the primary Prod Vault. This release makes these functions available in the secondary Prod Vault, supporting bi-directional updates to the synonym list.

Additionally, the connection name has been updated from CDMS Sync Synonym List to EDC Sync Coding Lists, since the connection includes Do Not Autocode lists.

Enablement & Configuration

This feature is automatically available in vaults using the EDC Sync Coding Lists connection across multiple Production vaults.

Imaging

The following are new features for Veeva EDC Imaging, the imaging exam module for Veeva EDC.

Imaging: Support 1GB DICOM Files 25R1.3

Use Case

The supported file size threshold for DICOM exams has been expanded from 50 MG to 1 GB, which allows Imaging to accommodate larger files within an exam, improving upload assurance and capability.

Description

Site users can now upload larger sized DICOM files, up to a 1 GB file size for a single file in an exam. Updated notations in the UI remind site users as they are uploading files, Unzipped DICOM (up to 1 GB per file, 4 GB total).

Enablement & Configuration

This update is automatically available for studies using Veeva EDC Imaging.

Imaging: Patient Name Assigned as SubjectID During De-Identification 25R1.2

Use Case

To provide traceability within downstream viewing applications, the metadata for Patient Name contained in uploaded DICOM files is now assigned the Subject ID value during the de-identification process.

Description

During the process of uploading DICOM file(s), the system automatically de-identifies specific PI/PII metadata including the Patient Name. Previously, the system assigned an anonymized value for the Patient Name as part of the de-identification process. With this release, the Subject ID is now assigned to this field. The Subject ID will be seen when the file is downloaded or viewed outside of EDC. Note: Within EDC there is no visible change in the UI for Data Entry or Imaging end users. In EDC, the Patient Name will show the De-Identified tag:

This update applies only to the metadata value seen when viewing the file in downstream systems.

Enablement & Configuration

This update is automatically available for studies using Veeva EDC Imaging.

Reports & Dashboards

The following are new features for reports and dashboards in Veeva Clinical Data.

New Standard Reports 25R1.3

Use Case

These new standard reports provide improved visibility of information to Coder users, Lab Data Managers, and Vault Administrators as well as minimize the need to develop custom reports.

Description

This release introduces the following new standard reports:

Standard Template: MedDRA Coding Report (V4) - V4 updates the reporttype to include Coder notes.
Standard Template: WHODrug Coding Report (V4) - V4 updates the reporttype to include Coder notes.
Standard Template: JDrug Coding Report (V4) - V4 updates the reporttype to include Coder notes.
Standard Template: Lab Locations and Sites - This new standard report includes lab locations and the sites using those locations.
Standard Template: Lab Reference Ranges - This new standard report lists lab locations and the normal ranges they use.
Standard Template: Lab Item and Analyte Definitions - This new standard report details lab item definitions and analyte definitions used within a study.
Standard Template: Study Masters and License Keys in EDC Tools - A new standard report for Vault Owners to view the license key entered for each study in the Vault. (Note - the data in this report is visible to Vault Owners)

Enablement & Configuration

These reports are immediately visible to Vault Owners. Vault Owners must share the new Coding and Lab reports in order for them to be visible to other users.

Assessments

The following are new features for the Assessments area of Veeva EDC.

Subject Filter Added to Assessments Grid 25R1.2

Use Case

We’ve added a new Subject filter to make locating and searching for subjects within the Assessments tab easier.

Description

The Assessment grid now includes a Subjects filter, which is located between the existing Site Number and Reassessments filters. The new text search is not case sensitive, alphanumeric, and will search subject IDs from left to right.

Enablement & Configuration

This update is automatically available.

Study Design & Configuration

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

Schedule Grid Improvements for Dynamic Rules 25R1.2

Use Case

These enhancements for viewing dynamic rules provide better usability and clarity for study designers when working within the Studio Schedule Grid.

Description

Updates seen within the Studio Schedule Grid include:

A new icon for dynamic Forms, Events, and Event Groups where no rule is configured. On hover over the icon, the tooltip message displays “No rule. Click to add.” and opens directly to the Rule Editor on click.

Count of rules (active + inactive) configured for the dynamic object: “View rules (#)” appears when hovering over the dynamic rule icon ().
New dialogue when clicking the dynamic rule icon displays additional details of the rule(s).

Enablement & Configuration

These updates are automatically available in Studio.

Labs: Fasting Status & Female Cycle Support for Normal Ranges 25R1.3

Use Case

Lab Normal Ranges can now be managed based on Fasting Status and Female Cycle, eliminating the need to maintain duplicate analytes for these scenarios.

Description

Lab normal ranges can now use Fasting Status and Female Cycle as parameters in the same way that Sex, Age Range, and Effective Date are currently used. Lab forms can be configured to collect Fasting Status and/or Female Cycle at the time of collection where applicable. This information can then be used to identify the appropriate normal range value.

Studio

Study builders can indicate if a lab form should include Fasting Status or Female Cycle in the lab header by modifying the Lab Header Settings in the Item Group property panel:

Selecting Yes triggers the addition of system-generated LBFAST and LBFEMALECYCLE items to the Lab Header for the form. These items will also be included in Extracts, Clinical Reporting, and CDB, if applicable.

Lab Settings

We’ve added a new Labs codelist for Fasting Status to System General Settings, with options Yes, No, and Unknown. The Female Cycle codelist was added in a previous release. Vaults created after 25R1 include an option for Pregnancy in this codelist. Users can add this option in older vaults if needed.

Normal Ranges

The Normal Ranges grid has been updated to include columns for Fasting Status and Female Cycle by default. These columns can be moved or removed using the Edit Columns option.

Lab Data Managers can configure normal ranges for analytes impacted by Fasting Status or Female Cycle as needed.

The Normal Ranges import file has also been updated to include an optional column for Fasting Status. The Female Cycle column was added in a previous release.

When evaluating normal ranges, the system will first try to match an exact value for Female Cycle and/or Fasting Status (as applicable). If there is no exact match, the system will use otherwise matching ranges where Fasting Status or Female Cycle is blank. Therefore, if an analyte is not impacted by fasting status or female cycle, these values can be left blank in the normal range.

Data Entry

When a lab form is enabled to use Fasting Status and/or Female Cycle, the form header will display the related questions to the Site. Data Entry users must provide a response or mark the item as Intentionally Left Blank in order to enable the lab panel and load normal ranges.

Enablement & Configuration

This feature is available in new studies. It can be added to existing studies with the creation of new lab forms.

Labs: Study Settings Error Messaging UI Update 25R1.3

Use Case

This update ensures accessibility and improves the consistency and clarity of the user experience.

Description

All errors shown on the Labs Study Setting page due to an invalid configuration have been updated to include a new error icon.

Enablement & Configuration

Auto-on.

Labs: Update to Preview and Update Outdated Lab Normals Jobs 25R1.3

Use Case

Running the Outdated Lab Normals job can break Signature, SDV, and DMR if changes result from the job. This feature documents that outcome in the Preview and Update Outdated Lab Normals job output files.

Description

The following columns have been added to the Preview and Update Outdated Lab Normals job output files, all of which will have a Yes/No value:

SDV Broken?
DMR Broken?
Signature Broken?

Enablement & Configuration

Auto-on.

Local Labs: Time Unknown for Lab Collection & Normal Range Effective Datetimes 25R1.3

Use Case

Lab sample collection date and time is used for the evaluation of lab normal ranges. Prior to this release, collection time was required. Now, studies can be configured to support unknown time values, simplifying the site user experience when collection time is not provided by the lab. Additionally, we have added the ability to enter unknown time for normal range effective datetimes for scenarios where the time is not provided by the lab.

Description

Lab Settings

Sponsors can now choose if lab collection time is required, allows unknown values, or is always unknown. This setting can be implemented from within System General Settings (default settings for new studies), but can also be set at the study level in Study General Settings.

The selected setting value is included in the Study Design Specification (SDS) exported from Studio.

Lab Location: Timezone Collection

Vault will now collect Timezone for each lab location to support more precise evaluation of Effective Start and End Dates/Datetimes for lab normal ranges and easier entry for Lab Data Managers. This field is required for newly created lab locations after the release, and is displayed in the Lab Locations grid and in the header of the Normal Ranges grid. All normal range effective datetimes entered for a lab location will be in the Timezone of the lab location.

For lab locations existing at the time of the release, the Timezone field will be populated in the following order as applicable:

Based on the entered address and country value for the lab location, if possible
Based on the timezone of the site to which the lab location is related, if the first option isn’t possible
If the lab location is not associated with any sites, the lab location timezone will be updated to match the Vault timezone
Customers are strongly encouraged to review the timezone settings for their lab locations after the release and edit as needed.

Lab Location Import File Updates

Lab Locations can now be updated via import to support better management of Lab Locations, including updating timezone values where needed after the release. Previously, the import supported only the creation of new lab locations.

When updating lab locations, the LabID is required. Other field values can be provided if the values are being updated. Blank values will not override existing values.
When creating or updating lab locations via import, supported timezone values should be used.

Lab Normal Range Management and Evaluation

The Effective Start and End Datetime values now support Unknown time. Lab Data Managers can use the question mark ( ? ) option when the time is unknown. With this change, time values must be entered in a 24-HR format.

All entered datetime values will be evaluated based on the timezone of the Lab Location. This will be compared to the Lab Collection Datetime value entered by the site which is evaluated based on the Site timezone.

Extracts

In the Study Data Extract (SDE) and EDC Core Listing, unknown time values will be output as UN:UN:UN.UNKZ and the data type of the field will be a string / char (SAS datasets). The length will be updated to 64 (SAS length 256).

If CDB is used, the datetime data type will be preserved, and the input time of 12:00 will be used. The datetime field’s RAW value will be displayed as a string using UN:UN.

Post Go Live Restrictions

A new casebook version is required to update the Lab Collection Time setting after deployment of a study to Production.

Enablement & Configuration

This feature is immediately available. Studies existing at the time of release will be set to require full date and time.

Repeating Item Group Data in Email Notifications 25R1.2

Use Case

Additional configuration options for email notification rules provide better visibility into data for email recipients.

Description

Email notification rules now support data coming from repeating item groups. When configuring a rule, study designers can add tokens for items located within repeating item groups to the Message area of the Send Email rule action. New tool tips for the Rule Action help guide study designers when including data from repeating item groups.

Email recipients will see the applicable data within one email notification for all item group repeats where the rule logic evaluates to true.

Enablement & Configuration

This update is automatically available in Studio.

Rule Editor Supports Country Code on @StudyCountry 25R1.2

Use Case

This feature allows study designers to program rules based on Veeva Vault Platform’s standardized country code values. The standard country codes, added as part of the 24R3 general release, provide a seamless connection between countries across different applications regardless of differing country names. These codes can now be used in the Rule Editor to ensure the rule always references the correct study country, even if the country name is changed by the Clinical Operations - EDC connection.

Description

The country code, @StudyCountry.country_code__v, is now available when creating rule identifiers in the Studio rule editor. As a best practice, study designers should use this reference instead of the country name text string when configuring User Defined Rules.

Enablement & Configuration

This update is automatically available in Studio. For Vaults created prior to 24R3, please contact Veeva Support to ensure the latest country codes are updated for the Vault.

Schedule-driven Default Data 25R1.3

Use Case

New Studio design selections increase standardization and design reuse by allowing repeating item groups to be configured with different default data at specific Events, Event Groups, and Forms within the casebook. Study designers can reduce development and testing effort by decreasing the overall number of unique Forms and further reuse Item Groups across unique Forms as required for the study design. This also reduces downstream effort in programming to combine Form data in reports and extracts.

Description

In the new Visibility Criteria tab, seen in the Default Data area of the repeating Item Group properties, study designers can set up the criteria that determines which default codelist item values are visible at various locations within the study schedule. After creating new visibility criteria, menu actions and checkboxes make it easy to see and select the rows to default. From the selection grid, study designers can select, hide or reorder the data defaults as required by the study protocol.

The default data can be assigned to specific Forms, Event Groups and Events. For repeating Event Groups and repeating Forms, sequence numbers can be entered to designate specific study schedule locations where the selected values will be defaulted. Configuration options dynamically adjust based on the identifiers and the study design. Validations and warnings assist designers to configure the default data correctly.

A new tab, Item Group Default Values, has been added to the Study Design Specifications (SDS) detailing the visibility criteria design configurations. Notations within the Annotated PDFs and appendix also include the visibility criteria. Following a deployment, changes to the criteria can be seen when running Comparison Reports in Studio. Visibility Criteria can also be copied from Studies and libraries.

Enablement & Configuration

This update is automatically available.

Studio Copy Improvements 25R1.3

Use Case

This feature allows Study Designers additional capabilities when copying from libraries or other studies to further study design reuse and reduce efforts when configuring studies.

Description

Copying capabilities within Studio have been added and improved to include the following features:

Copy Lab forms
- When the destination study has labs enabled, lab forms from the source study can be copied
System rules are always included when copying forms
- Univariates and Progressive Display rules will always be included when copying forms, these are copied as part of the form properties and independent from the checkbox to include rules
Added filters and improved searching when copying
- A new “Search by” filter in the copy dialog allows users to filter by All Fields, Name, Description, or Form
When selecting the checkbox to include rules during a form copy, user defined rules evaluate against the schedule to further ensure rules are copied successfully, resulting in fewer skipped rules.
Form copies will always run as a job, and provide a log regardless of the number of forms copied. This replaces the previous progress dialog when 20 or fewer forms were selected.

Enablement & Configuration

Automatically available in Studio.

Study Language for Studio Labels 25R1.3

Use Case

Previously, the Enforce Study Language setting needed to be set to “Yes” in order to see and save translations in Studio. This feature allows study designers to see the translated labels in Studio to ensure that the build is in the study language, particularly when the study language is different from the vault and user languages.

Description

With this feature, the system uses the value entered for Study Language, independent from the Enforce Study Language setting, in order to show and save translations in Studio. The design object labels in Studio will be saved in the selected Study Language and where translations have been uploaded for the study. This includes labels for Event Groups, Events, Forms, Item Groups, Items, and Codelist value labels, etc. If a study language is not selected, the labels will default to the vault language.

Note that application labels (non-study labels) will still show in the user’s language.

Enablement & Configuration

Automatically available in Studio.

Study Locking & Billing Enhancements 25R1.3

Use Case

These updates improve billing status clarity for non-ELA customers.

Description

We have updated the Billing Status option labels for non-ELA (Enterprise License Agreement) studies to provide greater clarity.

The Locked option has been renamed to Post-data Lock (this does not lock the study data). With this change, users will no longer be able to set the billing status to locked if the study data isn’t already locked.
The Archived option has been replaced with Decommissioned. Casebook creation and study deployments are not allowed for studies in the Decommissioned billing status as with the previous Archived status.

These updates are also reflected in the related dialog boxes.

We’ve also updated the dialog box displayed when study data is locked, to clarify that study data lock does not affect the billing status of the study.

Enablement & Configuration

These updates are immediately available for non-ELA (Enterprise License Agreement) studies.

Study Administration

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

Admin: Support VeevaID Username Update 25R1.3

Use Case

In 25R2, Platform updates to VeevaID now allow a user to update their username (i.e., email address). This feature supports visibility of these changes within EDC.

Description

To support the 25R2 Platform feature allowing VeevaID users to update their email address, we are making the following changes in EDC to show this change:

The User Activity Report has been updated to include username and email changes for both VeevaID and sponsor users.
The User Access report now references both the new and old usernames when access events occur after a VeevaID user updates their email address/username.

Enablement & Configuration

These updates are immediately available.

Enhancements to VeevaID & Veeva Training Reporting 25R1.3

Use Case

Users with multiple Veeva accounts may use a different account for CDMS Vault Training than for an EDC Vault. These updates clarify which username to use for training access.

Description

We are implementing the following enhancements to the Training Report and My Training tab:

Two column changes have been made to the User Training Report. These columns update approximately every 12 hours:
- Learning System Username: The logic for populating this column has been updated.
  - The report will display the VeevaID (site users) or Domain username (sponsor users) associated with the user’s training access.
  - If the training username is not yet available and the CDMS user is “Sponsor,” the Learning System Username column will be blank.
  - If the training username is not yet available and the CDMS user is “Site,” the Learning System Username column will display the CDMS user’s email address.
  - If the CDMS user has no user type, the Learning System Username column will be blank.
- VeevaID Registration Status: This column has been added to the report and displays the registration status of the VeevaID user (Registered, Invitation Sent, Invite Attempts Exhausted, etc.).
The Table on the My Training tab has been updated to display the training username for every training requirement.

When a user clicks the Training Access link on the My Training tab and needs a different username for login, the system will pre-populate the login screen with the correct Training username.
When the user in CDMS is the same as the user in Vault Training, the redirect to Vault Training has been improved to prevent re-authentication.

Enablement & Configuration

This feature is immediately available.

Use Case

Tooltip enhancements provide added details to help end users quickly identify which job options were included in the audit job.

Description

Hovering over the information icon next to the Audit Trail Export job within Job History will display the details of the job. The selected Date ranges, Users, Sites, Subjects, and options for Include the Definition, Relationship and Facade Audit Changes; and Include Medical Coding Audit Trail will be seen within the tooltip. When no selections are made, then the information icon will be hidden. The selections can be seen in the following jobs:

Audit Trail Export by Subject
Audit Trail Export By Site
Audit Trail Export by Study

Enablement & Configuration

This update is automatically available.

Rules Job: Close Queries for Inactive Rules 25R1.3

Use Case

Users with the Run Rules permission are now able to close queries that were opened by rules that are no longer active, reducing efforts for CRAs and Data Managers.

Description

From the Run Rules job in EDC Tools, inactivated Open Query rules can be selected and run in order to close open queries that were created when the rules were still active. The Rule Status filter can be used to locate specific rules that were initially active and subsequently inactivated in Studio and then deployed. When running the inactivated rules, a confirmation dialog allows users to review their selections before running the job. The output files from the rule preview job and the rule job will show the “Closed” Action in the associated job files. The Audit Trail and Query Details listings will show that the query was closed by System. Only queries in the Open status will be closed. Answered queries will not be closed. As part of this feature, the default view for Rules listed on the Rule job page is filtered to include only Active rules. Inactive rules can be added to the filter view by users when they need to run them. This helps prevent excess inactive query rules from being selected and run inadvertently.

Enablement & Configuration

This feature is automatically enabled.

Do Not Display Origin Site for CTMS Entry in Audit Trail 25R1.2

Use Case

This update improves the readability of audit trails by no longer displaying unhelpful ID values that provide no meaning to the user.

Description

In 25R1, we released updates to the Move Subject function, including stamping the origin site on Events and Protocol Deviations to support site payments handled in Clinical Operations Vaults. In 25R2, we will no longer display the entry for the Origin Site for CTMS value in the Event or Protocol Deviation audit trail UI, Detail PDF, or Audit Trail Export output, as the displayed ID value provides no value to the end user. The removed audit trail entry was in the following format: “Origin Site for CTMS” set to “[origin site ID number]” The audit trail entry for the action of moving the subject to a new site remains in the audit trail.

Enablement & Configuration

This update is automatically available.

Include Coder Audit Trails in Audit Trail Export 25R1.3

Use Case

The Medical Coding Audit history was previously visible only from within the UI. This release now makes this information exportable as part of an Audit Trail Export for review and analysis.

Description

The Subject, Site, and Study Audit Trail Export jobs now provide the option to include the Medical Coding Audit Trail.

To support usability of these audit trails, we are suppressing references to Label Keys and ‘All Caps’ values from both the Audit Trail UI and Export. This includes the following fields:

AE Action Taken Label Key
AE Expected Outcome Label Key
AE Outcome Label Key
AE Relationship Label Key
AE Seriousness Label Key
AE Severity Label Key
AE Action Taken AllCaps
AE Expected Outcome AllCaps
AE Outcome AllCaps
AE Relationship AllCaps
AE Seriousness AllCaps
AE Severity AllCaps
CM Course Number Label Key
CM Dose Label Key
CM Dose Unit Label Key
CM Frequency Label Key
CM Indication Label Key
CM Route Label Key
CM Course Number AllCaps
CM Dose AllCaps
CM Dose Unit AllCaps
CM Frequency AllCaps
CM Indication AllCaps
CM Route AllCaps
Verbatim AllCaps

Enablement & Configuration

Contact your Veeva Services representative to enable this feature in your vault.

Review Plan Assignment Audit Trail 25R1.3

Use Case

Data Managers and users with the Manage Review Plan Assignment permission can now see the audit trail for review plan assignments within EDC. This feature provides customers with better oversight on review plan changes without having to contact Veeva Support.

Description

Review Plan Assignment Audit Trail has been added as an option to the action menu on the Review Plan Assignment Criteria page. Selecting the Review Plan Assignment Audit Trail option will open the audit trail dialog for the review plan assignment record, showing the Event Description, Username, and Timestamp in the timezone of the user viewing the audit trail.

As part of this feature, the Archived column has been added to the grid and to both the CSV and Excel exports. A new Show Archived Assignments checkbox allows users to filter their view. The checkbox is unchecked by default.

Archived review plan assignments cannot be un-archived. Users must add a new assignment record after archiving. A dialog will warn users when archiving a review plan with the following message:

Review plans will not be assigned based on this criteria moving forward
Existing review plan assignments are not impacted
This action cannot be undone
You must create a new record in order to use the same criteria again

Enablement & Configuration

Auto-on.

S3 Extracts File Delivery Support 25R1.3

Use Case

Delivery to a customer’s Amazon S3 bucket expands options for delivering exports from the Veeva Clinical Data solution.

Description

A new external delivery option is available with this release: the ability to configure customer-owned Amazon S3 buckets to receive files from Veeva EDC and Veeva Coder. This additional delivery option allows jobs that are scheduled to deliver their files to the Amazon cloud after configuration in System Tools.

Enablement & Configuration

This feature is available to users with access to All Studies, System Tools, and the renamed permission, Manage Outbound Connections (formerly Manage FTP).

Clinical Operations-EDC Connection: Transfer of Closeout PDFs to Veeva Clinical Operations 25R1.3

Use Case

This automation streamlines the process of transferring Closeout PDFs to the Veeva eTMF and sites for archiving purposes by not only reducing the manual effort needed to transfer the individual documents, but also automatically storing and updating the Detail PDFs as one document per subject in Veeva eTMF.

Description

When closing out a site in a study, Veeva EDC allows a Closeout PDF containing Detail PDFs to be generated for each subject at the site. Previously the Closeout PDF could be downloaded from Veeva EDC for archiving. With this release, Closeout PDFs can also be automatically transferred to Veeva eTMF via the Clinical Operations – EDC Connection and shared with sites via SiteConnect. Re-generating the Closeout PDF in Veeva EDC will automatically update the relevant documents in Veeva eTMF via the Clinical Operations – EDC Connection. Once this feature is configured for the Clinical Operations – EDC Connection, every Closeout PDF generated for a study that uses the Connection will be automatically transferred to Veeva eTMF. Detail PDFs will be ingested by Veeva eTMF as individual documents, as configured. If the Closeout PDF generation fails, for example, if the Site Closeout is performed for a site without subjects, no PDF will be transferred. This functionality has no impact on the EDC user experience and can’t be tested in EDC. The appropriate Closeout PDF transfer must be traced in Veeva Clinical Operations.

Enablement & Configuration

This feature is automatically enabled for studies using the Clinical Operations – EDC Connection. The feature requires configuration in Veeva Clinical Operations.

Clinical DataBase (CDB) & EDC Clinical Reporting

The following are new features for the Veeva CDB application, EDC Clinical Reporting (the Veeva Clinical Data solution for data cleaning and reporting), or both.

Availability: Clinical DataBase (CDB) is only available to CDB license holders. Contact your Veeva Services representative for details.

Third Party Data Import Enhancements 25R1.3

Use Case

These enhancements to the handling of third party data (3PD) improves ease of use in CDB Workbench.

Description

This release includes two enhancements to third party data import in CDB Workbench:

For an Open EDC study, when the first package of a 3PD source fails to load, CDB will no longer block data import from any other sources in that study.
The manifest builder JSON will export in a more human readable format.

Enablement & Configuration

These enhancements are automatically available with the release.

CDB Automatic Table Splitting 25R1.3

Use Case

This is a self-healing operation that previously required a support ticket for Veeva to address.

Description

Large study designs or third party data import packages can cause ingestion failure, due to the size of the table required to store the data. CDB automatically splits these tables, but if a resulting table is still too large, the split size would need to be reduced to handle the large number of columns required. This release enables an automatic process where, if ingestion fails due to the design of the data, the system will retry ingestion with a smaller number of columns in each partial table, allowing ingestion to complete without requiring a Veeva Support ticket.

Enablement & Configuration

This feature is automatically available with the release.

Codelist Support for Third Party Data 25R1.3

Use Case

The ability to define codelist codes and decodes in the manifest allows for better control over reported values in a third party data set or in an OpenEDC study. This also supports transformation of codelist data values.

Description

Codelists for a source can now be defined in the manifest file, ensuring that reported data aligns with the definition of allowed values within that codelist, and transformation of entered data from coded to decoded.

Enablement & Configuration

This feature is automatically available with the release.

Enhanced Conditional Unblinding Rules 25R1.2

Use Case

To support more complex rules for unblinding data, we added additional operators for conditional unblinding rules.

Description

Conditional unblinding rules for text and number items (integer, float) now support the IN and NOT IN operators. This allows rules to easily check if an item’s value matches (or does not match) any value within a single comma-separated list. This enhancement overcomes the previous limitation where a rule could combine a maximum of six (6) distinct conditions or condition groups, as one IN or NOT IN condition can now efficiently test against multiple values simultaneously.

Enablement & Configuration

This feature is automatically available with the release.

Enablement Change: Calculated Fields in SYS Listings 25R1.3

Use Case

These fields provide data that is available in the SDE to be included natively in CDB to be included in exports.

Description

With this release, the Calculated Fields in SYS Listings feature (25R1) is now enabled automatically for all customers. Prior to this release, this feature required enablement by Veeva Support.

See the Calculated Fields in SYS Listings release notes for more information.

Enablement & Configuration

This feature is automatically available with the release.

Exports: New Columns Added to Raw Core Listings 25R1.2

Use Case

Additional Lab and Coding data offer more details in standard exports.

Description

The standard export now includes the Lab Modifier and Drug Code when using the Raw export type. The Lab Modifier provides, for example, greater than or less than modifiers for lab values. The Drug Code shows as DrugCD in forms that use the WHODrug dictionary for medical coding. These changes will be highlighted with change detection for existing exports.

Enablement & Configuration

This feature is automatically available with the release.

Manual Refresh of Non-Production Review Listings 25R1.2

Use Case

To reduce the system processing for test studies that don’t need to be continuously refreshed, we removed the job that runs hourly to refresh review listings. Instead, users can refresh listings on demand in non-production study environments.

Description

This release introduces a new Refresh option for Review Listings in non-production study environments to allow study builders and testers to refresh the listing on demand. This will reduce the burden on the system of continuously running hourly jobs that are not needed, and speed up processing time for testers and study programmers to get a listing refreshed as needed, instead of waiting for the queue to process the listing

Enablement & Configuration

This feature is automatically available with the release.

Use Case

The new banner provides better visibility when incremental ingestion is paused in Clinical Reporting and CDB Workbench.

Description

The Import page in CDB will display a banner when incremental ingestion (the every 15 minute update of data into a study from Veeva EDC) has paused due to a change to the study design or an unexpected load error.

Enablement & Configuration

This feature is automatically available with the release.

Study File Format (SFF) API Update: Deduplication of CSV Columns 25R1.3

Use Case

Duplicate column names in the SFF API can cause problems with downstream systems.

Description

If multiple columns have the same definition name, the system will append “_n,” starting with n = 1, for each duplicate column. The first column will maintain the original name, with each successive column being updated with the appended suffix. The manifest file has been updated to reflect this new naming convention.

API versioning and package versioning for SFF will be separate. In 25R2, a new package version, 2.0, will be generated for all extractions.

Enablement & Configuration

This feature is available automatically with the release.

CDB Export API: Run and Export Existing Definitions 25R1.3

Use Case

API exports offer more flexibility in starting an export job and retrieving the files.

Description

New API calls have been created for both CDB Workbench and Clinical Reporting. These calls allow users to retrieve study information and run and retrieve export definitions via API. Learn more about these new API calls in the Developer Portal.

The CDB API Read Write standard role (available to customers with CDB Workbench) has been updated to include the following permissions:

View Export
View Export Packages
Generate Export Package
Create Export Definition
Clinical Reporting Tab

Enablement & Configuration

These new APIs and the automatically assigned permission updates to the CDB API Read Write role are available after the release.

Maintain Review After Data Change 25R1.3

Use Case

This feature enables Data Managers to know when data in a Review Listing row has been changed after its review status was set. It does this while maintaining the latest review status and comments.

Description

Once a row in a Review Listing has the review status set, if data changes, a delta icon (Δ) will be displayed. The user can then dismiss the delta, retaining the existing status and comments, or update the status as needed. A new column on the review Dashboard will also display these delta changes, showing a count of rows with changes. Review listings with changes will count as not complete in the Review Dashboard and the Clean Patient Tracker.

Review Listings included in an export will include a new column that denotes whether data changed in a previously reviewed row.

Enablement & Configuration

This feature is automatically available with the release.

Observations Enhancements 25R1.3

Use Case

These enhancements include allowing a user to be tagged in an observation, a new standard Observations listings page, and including observations in custom listings and extracts.

Description

Users with View All Listings and View Observations permissions can be assigned to an observation. This allows for tracking multiple reviews, facilitating questions between colleagues on a data item, or enabling other forms of collaboration on data review.

Similar to Query listings, a new Observations page is now available, including standard listings for open or pending observations, all observations, and all observation messages. From this page, you can filter observations and navigate to the listing where the observation was created. These standard listings can be included in export definitions.

Summary links from listings are also available. These links navigate the user to the All Observations listing, filtered to show observations created from that listing.

The @OBS and @OBSMSG CQL syntax is now available for use in a custom listing, which can then be included in an export definition.

Query summary links are now available. These links navigate the user to the All Queries listing filtered for queries generated from that listing.

Enablement & Configuration

These features are automatically available to users with Observations permissions (View, Create, Reply, Close).

CDB CPT Site & Subject Charts 25R1.3

Use Case

New charts in the Clean Patient Tracker (Subject page) in CDB Workbench provide more accessible and understandable visualizations of casebooks with remaining data cleaning and overdue data entry. The charts provide a high-level overview, letting Data Managers know and communicate the status of data cleaning and any overdue data entry from the site.

Description

Two new charts in the Clean Patient Tracker show information about data cleaning and data entry for casebooks in the study. A bubble chart shows the relationship between overdue data entry and data cleaning still required. The second chart, a bar graph, shows the number of subjects by status and their cleaning status.

Enablement & Configuration

This feature is automatically available with the release.

Integrations

Features in this section are new integrations with Veeva Clinical Data or enhancements to existing integrations.

Update to CMDS API Read Write and CDMS API Read Only Permissions for Protocol Deviations 25R1.3

Use Case

To prepare for managing Protocol Deviations via the API in a future release, we’re updating permissions for CDMS API users.

Description

The CMDS API Read Write standard role has been updated to include the following permissions:

View Protocol Deviations
Create Protocol Deviations
Edit Protocol Deviations

The CDMS API Read Only standard role has been updated to include the View Protocol Deviations permission.

Enablement & Configuration

The permission updates are automatically assigned to the CMDS API Read Write and CDMS API Read Only roles with the release.

Safety-EDC Connection: Safety Case Follow-Ups Honor Safety Decisions 25R1.3

Use Case

Via the Safety-EDC Connection, Veeva EDC sends subject data to Veeva Safety not only as part of the actual Safety Case, but also as additional subject information to allow insights beyond the case data. This additional subject information can be added to a Veeva Safety case by simple selection. Subject information can also be removed from the case. A case can contain several events that are being split into individual cases on the Safety side or cases that are merged into one.

Veeva EDC is now aware of those safety decisions. While the EDC clinical data and site linking decisions remain unchanged, the decision taken in Veeva Safety about adding, removing, spitting or merging will be honored when compiling the next Follow-Up Send.

For example, a concomitant medication may be added in Veeva Safety. This feature guarantees that the Safety Case receives a Follow-Up Send if changes are made to that Concomitant Medication form, which isn’t linked by the site in EDC. Prior to this release, there would have been no Follow-Up Send because the form wasn’t linked by the site.

Description

Safety decisions in Veeva Safety include adding and removing additional subject information, or splitting and merging cases. Veeva EDC is notified of these actions and honors the decisions taken in Veeva Safety for smarter case Follow-Up Sends.

This functionality has no impact on the EDC user experience and can’t be tested exclusively in EDC, but requires integrated testing with Veeva Safety. The appropriate Follow-Up creation upon safety decisions in Veeva Safety and data changes in Veeva EDC must be traced in Veeva Safety.

Enablement & Configuration

This feature is automatically enabled for studies using the Safety-EDC Connection.

Use Case

To allow more flexibility for complex study designs, item groups embedded in the safety case initiating event, usually the Adverse Event EDC form, can now be included in the safety case. These repeating item groups would usually cover study drug dispenses, drug history, in case of death, medical history or test results on the adverse event form, and no standalone form is set up in the study design. With this ability, relevant information can be entered - as necessary - by a site user when an event will initiate a safety case for the subject.

Description

In Studio > Safety Integrations > From Configurations, a study designer can now map the EDC form already mapped with the Safety Case Initiation *data type to other data types, including *Concomitant Medications, In Case of Death, Medical History, Drug History, Study Drug, or Test Results.

The exception is a second mapping to the Safety Case Initiation Event or Patient Characteristics data type.. The Reporter / Sender Comments by System data type already supported dual usage on the Safety Case Initiation Event data type.

If an EDC form already mapped to the Safety Case Initiation Event data type is being mapped to another safety data type, the Each Entry In field now autoselects Repeating item group in form. Note that the Each Entry In *field for the *In Case of Death, Patient Characteristics, and Reporter / Sender Comments by System safety data types only allow the Form option for this field.

This new feature is supported by the Copy Forms functionality and reflected in the Study Design Specification (SDS).

Enablement & Configuration

This feature is automatically enabled for studies using the E2BLink.

E2BLink: Study Drug Indication on Study Drug Safety Type 25R1.2

Use Case

The Indication as Reported by the Primary Source (G.k.7.r.1) captures the reporter’s description of the indication for the study drug use. While this might be a single value for all subjects in a study, or per subject, this new option allows the configuration for the indication to vary from dispense to dispense on the main study drug. If multiple values are used across the subject casebook, all will be included in the E2B XML.

Description

For E2BLink studies, from Studio > Form Configurations > Item Configuration, users can now map G.k.7.r.1 (Indication as Reported by the Primary Source) to an Item Definition on the Study Drug data type.

Enablement & Configuration

This feature is automatically enabled for studies using the E2BLink. Configuration for a live study might result in follow-up safety messages for existing safety cases.

Safety Integration: Inclusion of Secondary Event Site Links into the Safety Case 25R1.3

Use Case

Safety cases are initiated by the primary Safety Case Initiating Event, which is most commonly a serious adverse event. Based on the inclusion rules in the safety integration setup in Veeva EDC, other secondary events, which are typically non-serious adverse events, can be included in the case. These events can be linked by the site to additional safety case relevant information, including concomitant medication and medical history. While this linked information could always be included in the safety case for the primary initiating event, this information can now also be included for secondary events that are part of the safety case.

Description

This new study setting is available for both the Safety-EDC Connection and the E2BLink.

In Studio > Safety Integration > Safety Settings, users are now able to configure the study to Include Secondary Event Site Links to Case.

Setting this field to Yes results in the inclusion of all configured data from forms that are linked to any secondary event into the case. Note that this is set to Yes by default in all new Studies.

For the Safety-EDC Connection, all unlinked safety-relevant data will still be transferred to Veeva Safety and made available as additional subject information, beyond the new information now included in the actual safety case.

As part of this feature, we renamed the Safety Form Type label in Safety Integration > Form Configuration to Safety Data Type to better reflect the type of data transfer.

Enablement & Configuration

This feature is automatically enabled for studies using the Safety-EDC Connection or E2BLink. Configuration to include secondary event site links for a live study might result in follow-up safety messages for existing safety cases.

Clinical Operations-EDC Connection: Send Event Group Definition-Event Definition Relationships to CTMS 25R1.3

Use Case

Currently, the Clinical Operations - EDC Connection automatically transfers Visit Group Definitions and Visit Definitions from Veeva EDC to Veeva CTMS but does not transfer the relationships between them. This feature enhances the Clinical Operations - EDC Connection by enabling it to create and manage relationships between Visit Group Definitions and Visit Definitions in Veeva CTMS. It bases these relationships on the corresponding Event Group Definition - Event Definition objects in EDC. This enhancement provides a more detailed and accurate representation of study visit structures in Veeva CTMS, leading to better management and alignment with study protocols.

Description

If this feature is configured for the Clinical Operations - EDC Connection, for each related Event Group Definition - Event Definition record found in EDC, the system will either update an existing record in CTMS or create a new one. If a matching Visit Group Definition or Visit Definition is missing in CTMS, a user exception message is generated.

This functionality has no impact on the EDC user experience and cannot be tested in EDC. On the CTMS side, this feature enables Veeva CTMS to display Visit Group Definition - Visit Definition relationships.

Enablement & Configuration

In EDC, this feature is automatically enabled for studies using the Clinical Operations - EDC Connection. In CTMS, the new integration point must be activated to enable the feature.

EDC API

The following are new features for the EDC API. See our Developer Portal's release notes for more detailed feature information.

EDC API Features 25R1.3

This release includes the following features for EDC developers:

Study Country Optional for All Endpoints
Start Job for S3 Connection and Coding Audit Trail Support
Casebook Creation Controlled by Licensing and Billing Status

CDB API

The following are new features for the CDB API. See our Developer Portal's release notes for more detailed feature information.

CDB API Features 25R1.3

This release includes the following features for CDB developers:

Study File Format (SFF) API Update: Deduplication of CSV Columns
Export API: Run and Export Existing Definitions

EDC Migrator

Features in this section are new features for Veeva EDC Migrator.

Migration Vault Renamed to “Veeva EDC Migrator” 25R1.3

Use Case

For clarity and simplicity, we’ve updated the name of the system. This change also ensures consistency across Veeva applications and aligns with the 25R1 Name & Logo Changes feature.

Description

The Migration Vault system logo will be updated to display the name “Veeva EDC Migrator”.

Enablement & Configuration

This feature is automatically available with the release.

Automated Update Outdated Normals Job 25R1.3

Use Case

During study migration, any change that impacts lab normals (such as the recalculation of a missing subject’s age) previously required the Update Outdated Normals job to be run manually. This release automates that step.

Description

New functionality is now available to recalculate missing subject ages and run the Update Outdated Normals job, eliminating the need for manual intervention in these tasks.

Enablement & Configuration

This feature is immediately available for new migrations.

YAML Builder and Mapping Enhancements 25R1.3

Use Case

These updates add clarity within the YAML builder and its files and minimize the need for manual mapping.

Description

This release includes several enhancements:

Unit Item Definitions: Migration Vault now supports mapping Unit Item Definitions in the Form’s YAML and sending item unit data.
Lab Codelist Value Mapping: Prior to 25R2, lab codelists required manual mapping. With this release, the YAML Builder now supports the mapping of these items.
Rename YAML File for Log Events: Previously the file created by the YAML Builder was named events_unscheduled.yaml. It will now be named events_log.yaml.
YAML Builder: Within the Data Source option, “CDMS” has been renamed to “Veeva.”

Enablement & Configuration

These updates are immediately available.