New Features in 26R1 Limited Releases
26R1 Planned General Availability: April 10 & 17, 2026
25R3.5 Release Date: March 6, 2026
25R3.4 Release Date: February 20, 2026
25R3.2 Release Date: December 19, 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 EDC and CDB.
New Stable URLs for EDC Application Tabs 25R3.2
Use Case
We are working on an improved user interface and user experience for Veeva EDC as part of a multi-year effort to make our product more accessible. This release includes more stable URL routing as part of this effort.
Description
Application tabs in Veeva EDC will now be available with a stable URL. See the table below for more information.
| New Base URL | EDC Tab Name |
|---|---|
| #/app/page/data-entry | Data Entry |
| #/app/page/review-studies | Review > My Studies |
| #/app/page/review-study-sites | Review > My Study Sites |
| #/app/page/protocol-deviations | Review > Protocol Deviations |
| #/app/page/assessments | Assessments |
| #/app/page/studio-library | Studio > Library |
| #/app/page/studio-studies | Studio > Studies |
| #/app/page/imaging | Imaging |
| #/app/page/coder | Coder |
| #/app/page/labs | Labs |
| #/app/page/edc-tools | Tools > EDC Tools |
| #/app/page/coder-tools | Tools > Coder Tools |
| #/app/page/system-tools | Tools > System Tools |
| #/app/page/safety-integrations | Tools > Safety Integrations |
| #/app/page/job-manager | Job Manager |
| #/app/page/my-training | My Training |
| #/app/page/clinical-reporting | Clinical Reporting |
| #/app/page/randomization | Randomization |
| #/app/page/data-loader | Data Loader |
| #/app/page/workbench | Workbench (CDB) |
Note that existing pages and bookmarked pages will be redirected to the new application tab pages. However, if there are unexpected URL patterns used, existing bookmarks may appear broken.
Enablement & Configuration
This feature is automatically available.
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.
Updated Form Reset and Form ILB Dialogs 25R3.2
Use Case
We’ve updated specific UI components and information within the Form Reset and Form Intentionally Left Blank (ILB) dialogs to be consistent with other dialogs throughout the application.
Description
With this release, the warning and information icons within the Form Reset and Form Intentionally Left Blank (ILB) dialogs have been enlarged and the yellow and blue background boxes behind the dialog text have been changed to white.
The following changes have been made to the Form Reset dialog:
- “Close any associated system queries.” has been updated to “Delete all system queries and closed manual queries”
- “Type “RESET” to confirm that you want to reset this form” has been updated to “Type the keyword RESET to proceed”
The following changes have been made to the Intentionally Left Blank dialog:
- The button text has been updated from “Submit” to “Mark as Blank”
Enablement & Configuration
This feature 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.
Protocol Deviation Enhancements: CTMS-Managed PDs 25R3.2
Use Case
This feature improves alignment between Veeva EDC and Veeva CTMS. Since the Clinical Operations-EDC Connection is one-directional, changes made to a Protocol Deviation (PD) in EDC can inadvertently overwrite data managed in CTMS. By restricting editing capabilities in EDC for connected studies, this enhancement establishes CTMS as the primary management tool for Protocol Deviations.
Description
For studies connected to Veeva CTMS, this update changes how users interact with Protocol Deviations in EDC. Once a PD is created in EDC, the ability to edit the deviation fields within EDC is disabled.
When viewing a CTMS-managed Protocol Deviation, the following applies:
- The Edit button is disabled. Hovering over the button displays a tooltip explaining that the record is managed in CTMS.
- Users can view the full details of the Protocol Deviation and its audit trail.
Users can manually inactivate a PD in EDC with a new option labeled Inactivate Protocol Deviation in the Action menu. This option is useful if the deviation has already been marked as inactive in CTMS.
Selecting Inactivate Protocol Deviation triggers a confirmation dialog where the user must provide a Reason for Change. If the deviation was not already inactive in CTMS, the connection will update the status based on the change made in EDC.
Enablement & Configuration
Contact Veeva Support for enablement. Immediately after the release, connected studies will no longer be able to edit Protocol Deviations in EDC.
Clinical Coding
The following are new features for Veeva Coder, the clinical coding area for Veeva Coder.
Display Freeze & Lock States in Coder for Queries 25R3.2
Use Case
Currently, Coder users did not know if the EDC data associated with a coding request is frozen, which leads to delays when querying frozen data only to find out through a Site query response that the data must be unfrozen. This feature adds clear visual indicators in the form of banners in the Query Panel in Veeva Coder, enabling coders to quickly identify data that requires action from other teams. This improves the Coder workflow and speeds up the process when data needs to be unlocked or unfrozen for querying purposes.
Description
This enhancement displays banners within the Query Panel in Coder to display the Locked or Frozen status of the source EDC data for a given verbatim. The behavior when data is Locked remains the same and queries cannot be posted to locked data. The banners are displayed above the Search Query Templates box or the ‘Submit a Query…’ free-text input field. Depending on the view mode, Coder users can be provided with the following information:
Locked Data
-
List Mode error banner text: “Queries can’t be posted, closed, or autoclosed because the corresponding form is locked.”
-
Grouped Mode error banner text: “The corresponding forms are locked and cannot receive queries.”
In Grouped Mode view, the banner will display as long as at least one form in the group is locked.
When data is locked, the Search Query Templates box (if present) and the Submit a Query text input field are disabled, preventing query actions. This is a change to the existing design where, instead of an error banner, the information about the form being locked was displayed directly in the ‘Submit a Query…’ text input field, which no longer displays that information.
Frozen Data
-
List Mode informational banner text: “Data is frozen.”
-
Grouped Mode informational banner text: “The corresponding data is frozen.”
Note that in the **Grouped Mode **view, the banner will display as long as at least one verbatim in the group of code requests is frozen.
Unlike with locked data, when data is frozen the query input fields remain enabled. Freezing affects the data source but does not prevent the ability to enter a query.
Enablement & Configuration
This feature is automatically available.
Coder Query Audit Trail Enhancements 25R3.2
Use Case
Currently, when a user has access to both the Coder and Review tabs and edits a message associated with a Coder-related query from the Review Tab, the system’s audit trail doesn’t accurately reflect the edit as a separate event in Veeva Coder. This makes it difficult to track the history of changes to the query’s message.
The enhancement ensures that all changes to a Coder Query message are tracked with a clear, separate audit entry, improving audit completion and meeting regulatory compliance and audit needs.
Description
With this feature, the Coder Audit Trail creates a new, separate audit entry whenever the message of a Coder-related query is edited, rather than simply updating the original audit entry with the new message. This change ensures that both the original query message and all subsequent edits are clearly recorded and visible in the Audit Trail. It also improves consistency between the Item Audit Trail in EDC and the Audit History in Coder.
Enablement & Configuration
This feature is automatically available.
Coding Administration
The following are new features for Coder Tools, the administration area for Veeva Coder.
Update Coding System Label to Veeva Coder 25R3.2
Use Case
In line with the recent update of Vault application branding from Vault [Application] to Veeva [Application], the product name for the Coding System and all system references now use the updated name, Veeva Coder. This change ensures consistency in product naming across all Veeva applications.
Description
This feature updates the product name displayed for the Coding System in all system references, including Coder Tools > Study Settings. With this release, the label for the Coding System is updated from Vault Coder to Veeva Coder.
Enablement & Configuration
This feature is automatically available.
Imaging
The following are new features for Veeva EDC Imaging, the imaging exam module for Veeva EDC.
Imaging: Update DICOM De-identification Profile 25R3.2
Use Case
DICOM images often contain a large volume of metadata, including sensitive patient health and identifying information (PHI/PII). This feature ensures that the system’s DICOM de-identification process and profile are current with the latest DICOM standards (specifically, 2025c). The automated de-identification process now covers newly defined tags, ensuring the system’s ability to reduce risk and maintain compliance.
Description
Veeva EDC Imaging’s security profile has been updated to include all tags defined in the DICOM standards up through release 2025c. This ensures the Tag Browser correctly displays all available tags.
The existing de-identification process is updated to include new DICOM tags.
- For each DICOM file, the system will identify new tags flagged for ‘DEID’ (De-identification).
- The original values of these new tags will be replaced with de-identified dummy values.
This update is a background change to the system’s data management and does not include any changes to the existing user experience (UX) or workflow.
The list of the DICOM tags that have been incorporated into the de-identification profile from release 2024c through 2025c:
| Attribute Name | Tag | Dummy Value |
|---|---|---|
| Ethnic Group Code Sequence | (0010,2161) | SQ |
| Ethnic Groups | (0010,2162) | UC |
| Gender Identity Code Sequence | (0010,0044) | SQ |
| Gender Identity Comment | (0010,0045) | UT |
| Gender Identity Sequence | (0010,0041) | SQ |
| Histological Diagnoses Code Sequence | (0008,1304) | SQ |
| Montage Channel Label | (0040,B03F) | LO |
| Montage Name | (0040,B03B) | LT |
| Name to Use | (0010,0012) | LT |
| Name to Use Comment | (0010,0013) | UT |
| Person Names to Use Sequence | (0010,0011) | SQ |
| Primary Diagnosis Code Sequence | (0008,1302) | SQ |
| Principal Diagnosis Code Sequence | (0008,1301) | SQ |
| Pronoun Code Sequence | (0010,0015) | SQ |
| Pronoun Comment | (0010,0016) | UT |
| Secondary Diagnoses Code Sequence | (0008,1303) | SQ |
| Sex Parameters for Clinical Use Category Code Sequence | (0010,0046) | SQ |
| Sex Parameters for Clinical Use Category Comment | (0010,0042) | UT |
| Sex Parameters for Clinical Use Category Reference | (0010,0047) | UR |
| Sex Parameters for Clinical Use Category Sequence | (0010,0043) | SQ |
| Third Person Pronouns Sequence | (0010,0014) | SQ |
Enablement & Configuration
This feature is automatically available.
Study Design & Configuration
Features in this area apply to Studio, the study design and configuration area for Veeva EDC.
Studio Casebook Version Update 25R3.2
Use Case
New fields seen when creating and editing casebook versions help Study Designers provide better references for amendments. The casebook version name and external ID can now be updated during the development and testing of post-go-live changes.
Description
When editing or creating a casebook version, the external IDs can now be set uniquely to each new casebook version. Study Designers can update the casebook definition (version) name, reason for change, description, and external ID for non-published study versions.
New optional fields, Description and External ID, are available in the Create New Version dialog. The fields Reason for change and External ID are now included in the Edit Casebook Version dialog, allowing designers to amend these values while updating the study design. Also, for clarity, the title of the Edit dialog has been updated to Edit Version Properties: [version number].
The field lengths are enforced with on-screen error messages when exceeding the character limits:
- Name (128)
- Reason for change (255)
- Description (256)
- External ID (128)
The properties of previously published versions and versions with a Validating status are viewable from the new View Version Properties Studio menu option. Selecting this opens the View Casebook Version dialog as read-only.
Enablement & Configuration
This feature is automatically available.
Increase Studio Help Content 25R3.2
Use Case
The Help Content character limit in the properties panel in Studio has been extended to allow for longer descriptions so as to better inform site users during data entry.
Description
The character limit for the Help Content field within the Studio object properties panel has been increased to 1500. This change applies to the Help Content field for Event Groups, Events, Forms, Item Groups, and Items. Users will encounter a warning and be required to reduce their character length before saving when exceeding 1500 characters.
Enablement & Configuration
This feature is automatically enabled.
Rule Emails Should Display in Study Language & Locale 25R3.2
Use Case
Emails resulting from Send Email rules previously appeared in the user language/locale of the site user whose data entry triggered the email. With this release, the data in the emails will appear in the study language and locale. This change helps to align the data and email content in cases where the user’s language/locale differs from the study language/locale.
Description
When Study Language is enforced, the following data points included in the Send Email rule will display in the study language and locale:
- Date & DateTime Items
- Codelist Items
- Visit Method
- Event Date
When Study Language is not enforced, the data points included in the email will display in the user language and locale.
Additional aspects of the email subject and body will display according to the Rule Action, as configured by the study designer.
Enablement & Configuration
This feature is automatically available.
Enforce Reciprocal for Expression Engine v2 Rules 25R3.2
Use Case
This feature enforces consistent reciprocal behavior for rules within studies using Expression Engine v2. It helps ensure rules with a mix of @Form floating identifiers and fully qualified identifiers adhere to their intended behavior, re-evaluating as expected when the other identifier is submitted.
Description
For studies using Rules Expression V2, new rules and rules being copied into the study will enforce “Yes” for the Reciprocal value and this value will not be editable by Vault Owners in the administration area (Business Admin, Rule Definitions).
Differences in a rule’s Reciprocal setting will be included when comparing studies, even if the studies are on different Expression Engine versions. Rules that have had their Reciprocal field value changed from No to Yes will also be included in the Validation Test Script file.
Enablement & Configuration
This feature is automatically available for studies using Expression Engine v2.
Enforce Valid Derived Item Configurations 25R3.2
Use Case
New Studio restrictions and validations help Study Designers properly configure system edit checks, progressive display, and default data related to Derived items, preventing production issues caused by these improper Studio configurations.
Description
System Edit Checks (Item Properties)
When the Item Type of an item is changed to Derived and saved, EDC now automatically archives any active system edit checks associated with that item (for example, Required, Future Date, and Range checks). This ensures that Required, Future Date, and Range checks are not auto-generated in Data Entry for items which cannot be revised by site users. For previously added edit checks on the derived item, a new dialog informs the designer which system edit check settings will be archived.
Progressive Display
The system now prevents the use of derived items in Progressive Display rules when the visibility is set only to Include in Extracts. When revising a derived item and the Display Visibility property only specifies Include in Extracts, and Progressive Display rules are included, Studio will automatically archive the Progressive Display rules, displaying a new Impacted Objects dialog. The Progressive Display section will then be hidden from the item or item group’s Properties panel.
For existing, invalid, configurations (on either an item group or item), a warning icon and notification appears within the drag and drop editor. A warning banner with the Clear Progressive Display button is displayed within the Properties panel, allowing users to correct the configuration and archive the rules.
Warnings will also be included when running the Casebook Validation if the study contains invalid Progressive Display configurations with derived items.
Default Data
Derived items will no longer appear as available columns to configure Default Data. Items that are configured as Default Data cannot be changed to be a Derived item type.
Study designers can now clear entire columns configured for Default Data using a new eraser icon next to the item columns. If Derived items were previously included within Default Data, the column will now appear with a warning icon and orange highlighting. A red banner at the top of the grid will notify users that they are required to delete the column in order to save changes to the Default Data configurations.
Warnings will also be included when running the Casebook Validation if the study contains invalid Default Data configurations with derived items.
Enablement & Configuration
This feature is automatically available.
Display Item's Previous Submit Value in Email Messages 25R3.2
Use Case
Study Designers can now configure the previous value of an item to be included within the Message of Send Email rules. Seeing the previous and current value within the email body can be particularly useful for sending emails related to Adverse Event (AE) and other forms.
Description
When configuring User Defined Rules in Studio, the .previous_submit_value__v item attribute is now available as a token for including in email messages. Study Designers will see the additional token within the Action section of the Send Email rules and can use this token to provide the item’s previous data value within the body of the email.
Example: ${Custom.@Form.igAE.AESER.previous_submit_value__v}
Enablement & Configuration
This feature is automatically available.
Study Administration
Features in this section apply to System Tools or EDC Tools, a study-level administration area for Veeva EDC.
Redesign Rule Job Output File 25R3.2
Use Case
The output files of the Run Rules job (EDC Tools) have been redesigned to provide more comprehensive details about rule execution results. This change helps Study Designers and Data Managers gain a more complete understanding of the expected behavior when running revised rules.
Note: This feature includes updates to the .csv files that take effect in the 25R3.2 limited release. More updates in the upcoming 25R3.4 limited release will consolidate the individual .csv output files into one single file with separate tabs, and will provide additional enhancements.
Description
When running the Run Rules job, the resulting output files now incorporate the following updates:
| File | Column | Rule Type | Summary of Change |
|---|---|---|---|
| All | All | All | Object names are now displayed instead of labels |
| For studies where the Study Language is enabled, the files will now be translated. | |||
| rule_details.csv | Action | All | "None" Action: An Action of "None" is generated for rules that were either selected but did not execute (e.g., bound form did not exist) or ran but resulted in no action. |
| Add Form, Add Event, Add Event Group |
|
||
| Open Query |
|
||
| Create Protocol Deviation, Create Integration Record |
“Created” replaces "Added" to describe create actions | ||
| Set Derived Value |
|
||
| Set Subject Status | New Actions include Subject Status History Updated, Subject Status Rolled Back (replaces “Unset to [Status]”), Prior Status Rolled Back, and Skipped | ||
| Rule Result | All | This column is now populated for all rule types. All rules except Set Derived Value will display TRUE or FALSE. Set Derived Value rules will display the Derivation Result. | |
| create_delete_dynamics_details.csv | All | All | Dynamic object names are now displayed in their full hierarchy (e.g., Add Form rules will now show the name of the specific Event and Event Group where the action occurred). |
| Action | All | Action labels have been updated to match the rule_details.csv file | |
| dynamics_summary.csv | All | All |
Column headers have been updated to match the corresponding Action labels.
Note: The [Object] Added columns will not be usable in the 25R3.2 release, as they will not be incremented and will remain 0. |
| errors.csv | N/A | N/A | Permutation errors during rule execution are now captured and included |
| Errors are now identified using GUID, which replaces the technical Failure Reason message |
Enablement & Configuration
This feature is automatically available.
Labs
Features in this section are new features for the Labs module of Veeva EDC.
Remove Automatic Addition of Trailing Zeroes to Lower & Upper Normal Range Values 25R3.2
Use Case
Currently, when a user enters Lower or Upper Normal Range values, the system automatically adds trailing zeroes based on the Analyte’s precision setting before saving the record. This behavior can cause problems because the saved data does not exactly match what the user entered. More critically, if an Analyte’s precision is updated later, running an Update Outdated Normals Job can add more trailing zeroes, potentially breaking downstream processes like SDV, DMR, and Signatures.
Description
This feature changes how Lower Normal and Upper Normal range values are stored in the system to ensure that saved data matches the user’s input without added trailing zeroes.
With this release, the automatic addition of trailing zeroes has been removed, so that the Lower Normal and Upper Normal range values are saved exactly as the user inputs them. This functionality maintains data integrity and prevents downstream validation breaks caused by changes in Analyte precision.
Previous behavior:
Updated behavior:
This feature also prevents the user from saving analytes that are not a Number or Unit data type and includes updated error messages for those instances.
Enablement & Configuration
This feature is automatically enabled in GR. Contact Veeva Support for LR enablement.
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.
New Third-Party Data Type Validations 25R3.2
Use Case
Validations on data type ensure that the data adheres to the values described by the manifest, resulting in higher quality data and error detection during import.
Description
The system now provides new validations on numeric and text data types configured in the manifest, as well as support for MySQL BigINT numbers (i.e., numbers with greater than nine (9) digits).
Validations for the text Item Definition will ensure that the configured length is greater than zero (0) and less than or equal to 1500. New warnings D-039 for greater than 1500 and D-040 for length less than one (1) will display and set the values in the manifest if they do not conform to the minimum and maximum length for a text field.
Numbers defined as Float in the manifest will have new validations with warnings D-041 to D-046 to ensure that the Item Definition length is at least one (1) and does not exceed 24 digits. The configured minimum and maximum values cannot be less than -999,999,999,999,999,999,999,999 and cannot be greater than 999,999,999,999,999,999,999,999.
Numbers defined as Integer in the manifest will have new validations with warnings D-047 to D-052 to ensure that the Item Definition length is at least one (1) and does not exceed 18 digits. The configured minimum and maximum values cannot be less than -9,223,372,036,854,775,808 and cannot be greater than 9,223,372,036,854,775,807.
Enablement & Configuration
This feature is automatically available at the time of the release.
Manifest Builder Updates 25R3.2
Use Case
Enhanced features in the Manifest Builder ensure better data quality and provide a better experience for users building a manifest file (.json) to import third-party and OpenEDC data.
Description
The Manifest Builder has been updated with the following features:
- Required field validations in the Manifest Builder for the following data types:
- Text (length is required)
- Float (length and precision are required)
- Date, Date Time, and Time (format is required)
- Codelist (codelist is required)
- Configuration validations will display in the Manifest Builder:
- Text length must be between 1-1500 characters
- Integer length must be between 1-19 digits
- Integer minimum must be greater than or equal to -9,223,372,036,854,775,808
- Integer maximum must be less than or equal to 9,223,372,036,854,775,807
- Float length must be between 1-24 digits
- Float precision must be between 0-7 digits
- Float minimum must be greater than or equal to -999,999,999,999,999,999,999,999
- Float maximum must be less than or equal to 999,999,999,999,999,999,999,999
- The ability to upload codelists:
- New codelists or adding items to existing codelists
- Import template CSV available
- The text default is now set to 500
- Adding a new item to the manifest Item Mapping will no longer display the row in error on creation
- When data type is changed, any entered properties will be cleared
Enablement & Configuration
These features are available automatically at the time of the release.
Third-Party Data Import Notification When Pending Approval 25R3.2
Use Case
Users will now receive a notification when the package they uploaded is pending approval and requires action within CDB Workbench.
Description
The user who uploads a third-party data package will now receive a notification if the package is pending approval and requires action (approval). This occurs regardless of whether it is the first package from this source or a change to the previously approved package manifest.
This feature applies to both Veeva EDC and OpenEDC studies.
Enablement & Configuration
This feature is automatically available at the time of the release.
Additional Fields for the Clean Patient Tracker 25R3.2
Use Case
Additional columns allow for better review of subjects in a study and understanding of where in the schedule of events the subject is, especially when using repeating event groups.
Description
The Clean Patient Tracker now includes columns for Substudy and Latest Event Group to provide more context and filter options when viewing the tracker.
Enablement & Configuration
This feature is automatically enabled at the release.
Filter Menu Redesign for CQL Listings 25R3.2
Use Case
The operator option as a drop-down makes it more clear which operator the user selected.
Description
The Operator selector is now a drop-down menu.
Enablement & Configuration
This update is automatically enabled at the release.
CDB Grid Improvements 25R3.2
Use Case
Improvements to screen size utilization in a listing enhances the experience for users–either those using smaller screens, or wanting to focus their view of data better by moving the cell details panel to a new window while still viewing the listing rows, making reviewing data easier.
Description
This release improved listing screens to use the available space more efficiently. Users can now pop out the cell details panel, which will automatically maximize the grid. Users can also use a new dialog to show and hide columns, so you no longer need to select columns one at a time to hide or show individual columns.
Enablement & Configuration
This changes apply automatically at the time of release.
Support JDrug Coding Dictionary in CDB 25R3.2
Use Case
For studies with Veeva Coder that use the JDrug coding dictionary, the availability of JDrug in CDB supports more robust listings that include Japanese coded terms for drug forms such as Concomitant Medications.
Description
JDrug Coding Dictionary values are now available in CQL, Listing Builder, SFF, and Raw exports. Updates to Raw exports include new columns for DictionaryType and UserCodedBy, for all forms with MedDRA, WHODrug, and JDrug dictionaries configured. New JDrug dictionary values will apply to forms configured in Veeva EDC with the JDrug coding dictionary.
Enablement & Configuration
This feature is automatically available.
My Observations Assignments Filter in Review Listings 25R3.2
Use Case
Being able to filter a Review Listing to show only assigned Observations enables users to easily find and action the Observations assigned to them.
Description
Review listing filters have a new option, Observation Assignment, which filters to display only Observations assigned to the current user.
Enablement & Configuration
This feature is automatically available upon the release.
Update Review Listing Timing Thresholds 25R3.2
Use Case
Updates to the refresh timing allow for longer running listings to refresh on a limited basis.
Description
Review listing timing thresholds have been updated so that listings that run for longer than 30 seconds, up to 5 minutes, will be refreshed on a daily basis after 50 consecutive runs of greater than 30 seconds. CDB will automatically disable any listings that run over five minutes.
Enablement & Configuration
This feature is automatically enabled at the release.
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 Veeva Clinical Data.
New Query Team 25R3.2
Use Case
Three new specialized Query Teams offer more granular control over the assignment and management of queries.
Description
With this release, Veeva EDC introduces three new Query Teams: Medical Monitoring, Medical Review, and Pharmacovigilance. These new teams are now available as selectable options within the Team dropdown menu when administrators create or rename custom roles. Additionally, these teams can be selected in the “Query Team for System Queries” dropdown located in the Study Settings within Studio. No standard roles have been added to these new teams.
Enablement & Configuration
This feature is automatically available.
Connections & Integrations
Features in this section are new connections or integrations with Veeva Clinical Data or enhancements to existing ones.
Clinical Operations-EDC Connection: Aggregated User Exception Messages by Study Countries and Study Sites for Identical Issues 25R3.2
Use Case
If User Exception Messages (UEMs) for the Clinical Operations - EDC Connection are required due to an issue with data synchronization at the Study or Study Country level, several UEMs for each affected Study Country or Study Site might be created with the same error message. For example, if a study is locked, but the Clinical Operations - EDC Connection is not yet disconnected, any change that requires synching between Veeva CTMS and Veeva EDC would result in the creation of a UEM for every Study Country and every Study Site, as the lock would prevent their data synchronization. To reduce the number of UEMs, only one message, which lists all Study Countries and one message, which lists all Study Sites that are affected by the same error, are now being created.
Description
If the same Clinical Operations - EDC Connection issue affects more than one Study Country or Study Site, only one UEM is created for Study Countries (listing all affected Study Countries), and one UEM for Study Sites (listing all affected Study Sites), both showing the error message that affects all listed Study Countries or Study Sites.
Study Countries and Study Sites will be listed in the Item Data section of the UEM, respectively. This applies to error messages that read “Study is locked” and “Matching Study Country record cannot be found”.
Enablement & Configuration
This feature is automatically enabled for studies using the Clinical Operations - EDC Connection. This functionality can’t be tested exclusively in EDC but requires integrated testing with Veeva CTMS.
Safety-EDC Connection: Connection Configuration Available for Every EDC Vault 25R3.2
Use Case
To configure the Safety-EDC Connection to connect one or multiple Veeva EDC Vaults to a Veeva Safety Vault no longer requires contacting Veeva Support.
Description
The configuration of the Safety-EDC Connection can now be done by Vault Owner and Safety Administrators without involvement of Veeva Support.
Enablement & Configuration
This change applies automatically.