New Features in 25R1 Limited Releases
25R1 Planned General Availability: April 4 & 11, 2025
24R3.5 Release Date: February 28, 2025
24R3.4 Release Date: February 7, 2025
24R3.2 Release Date: December 18, 2024
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.
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.
Bulk Signature Flag & Button Updates 24R3.2
Use Case
To help alleviate confusion around signature capabilities, the “Sign Casebooks” button in Data Entry has been re-labeled to “Bulk Sign Casebooks”, and the button is now viewable on the Site grid page for all studies. These changes allow Primary Investigators to be more aware of the Bulk Signature features.
Description
Previous to this release, the Sign Casebooks button on the casebook grid page in Data Entry was hidden when bulk signature settings were not used for a study or site. The button is now visible for all studies. Similarly, in the site grid, the Bulk Sign Casebooks option is now visible in the action menu next to the site number. The button and menu option will be enabled or disabled as indicated from the Enable Bulk Casebook Signature setting in EDC Tools and the Bulk Casebook Signature site setting.
Hovering over the button in the casebook grid and the site grid action menu will display the applicable reason when the button is disabled.
Enablement & Configuration
Automatically available for all studies on all vaults, the button is no longer included as part of the Vault’s feature flag. The button and menu action will be selectable based on existing study and site settings within EDC Tools. New studies and sites will have the setting set to Yes by default.
ILB Behavior Update for Queries 24R3.2
Use Case
Previously in cases where site users marked items or the whole form as intentionally left blank (ILB), an existing query would be removed when ILB was selected.
Description
This feature changes the dependency from the ILB action to the rules engine and allows the rules engine to determine if the query will close. If the conditions of the rule are no longer true, then the query will automatically close, per the existing rules behavior.
Enablement & Configuration
These updates are automatically available.
Highlighting of Required Fields for Unscheduled Events 24R3.2
Use Case
Previously, while adding an unscheduled event site users were less aware that required fields were missing and in some cases confused about why the Save button was not enabled. This improvement to the unscheduled event dialog provides clarity to site users and a user experience that is more consistent with other areas of EDC.
Description
When adding an unscheduled event, the Save button now remains enabled. Required fields that are left empty are highlighted in the dialog and an error message is displayed underneath the field.
Enablement & Configuration
These updates are automatically available.
Query Team Updates for Single Team, Multi-role and Multi-site users 24R3.2
Use Case
Improvements have been made to the Query Team feature and query dialog. These enhancements help to clarify which query team is assigned while the query is being added and help automate the assignment of the accurate query team.
Description
Users with Multi-role and Multi-Site access: The system will now automatically assign the appropriate query team for the user when they are part of a single query team for that site. When using multi-role security, where the user’s roles are part of more than one query team for the site(s), the selector will display for the user to choose the appropriate query team.
Users with a single query team: When opening a query, the query dialog will immediately display the user’s query team. This helps show the user the team where they are entering the query.
Enablement & Configuration
These updates are automatically available.
SubjectID Case Sensitivity 24R3.4
Use Case
Items entered by sites or external systems which are used to create Subject IDs could have caused downstream issues when the same characters were used but the characters were differing in upper/lower case. This update enforces case sensitivity on subject IDs and prevents duplications from occurring as the Subject ID is added.
Description
Case sensitivity is included to prevent duplicate values for Subject IDs. This feature is applicable for studies configured in Studio with the manual Subject-ID setting. Site users will be presented with an on-screen error prompting them that the subject already exists for the site. The system-assigned screening ID (SCR-###) is retained when the user navigates away from the Form, until the Subject ID is revised. Case sensitivity also applies for Subject IDs populated by external systems using APIs. When the same Subject ID with different cases is sent, an error is received.
Enablement & Configuration
This enhancement is automatically available.
Usability Improvements for Item Change Reason 24R3.2
Use Case
Previously, in some cases when revising form data, site users were not able to continually see the selected change reason while the form was In Edit.
Description
To provide clarity and better usability, after the user selects a change reason for the item, the revised change reason will now remain displayed until the user submits the form. The change reasons from prior form submissions will not display during a subsequent In Edit session. Additionally, for studies using local labs, the change reason dropdown will not show until the user edits the value in the lab header.
While editing a form, if the user clears the change reason they will no longer see a blank selection. They will continue to see the drop down and the error text will display: “Error: Change reason is required”.
Enablement & Configuration
These updates are automatically available.
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.
Event Summary Updates: Event Date and Form Entry Overdue 24R3.4
Use Case
These enhancements help with the report processing and to better support studies using Data Model 2.
Description
A backend update has been made to the Event Operational Summary report type within the Reporting Area. The Event Date lookup field, which is a temporary field used to help process the report’s data, is now deprecated because it is no longer needed. The formula for the Form Entry Overdue Days calculation within the Event Operational Summary is updated to include Data Model 2 studies. The formula now considers both event__v.event_status__v and event_summary__v.event_status__v in its calculation.
Enablement & Configuration
This enhancement is automatically available.
Updates to Event Progress Listings 24R3.2
Use Case
To support study review activities, we’ve added new columns, renamed some columns, and updated the logic to improve the usability of the Event Progress Listing.
Description
- Added new columns to show where Re-SDV and Re-DMR are required when review was complete and then data changed and the review state was cleared
- The logic for Event Date and Visit Method Frozen, Locked, and Signed columns has been updated for Log events, which do not have event dates or visit methods, to display as blank instead of “No”
In addition, the following column names in the Event Progress Listing have been updated:
| Current Name | New Column Name |
|---|---|
| Event Date First SDV Complete Date | Event Date First SDV Completion Date |
| Event Date SDV Complete Date | Event Date SDV Completion Date |
| Visit Method SDV Complete Date | Visit Method SDV Completion Date |
| % Forms SDV | % Forms SDV Complete |
| Event Date First DMR Complete Date | Event Date First DMR Completion Date |
| Event Date DMR Complete Date | Event Date DMR Completion Date |
| Visit Method DMR Complete Date | Visit Method DMR Completion Date |
| % Forms DMR | % Forms DMR Complete |
| Freeze Date | Event Frozen Date |
| Lock Date | Event Locked Date |
Enablement & Configuration
This enhancement is automatically available with the release.
Learn More
Extract Job Governor Enhancements 24R3.2 24R3.4
Use Case
These updates allow for more flexibility for studies to schedule jobs multiple times per day without worrying about job options for Restricted data.
Description
We’ve removed Job Governor restraints based on Restricted status and increased daily limitations for certain listing jobs to four jobs per study. This feature affects the Study Data Extract job, Study Progress Listings jobs, and Study Progress Versioned Extracts jobs. The Restricted status constraint will be removed from the Study Summary Metrics Report and Additive Review Listing jobs but those jobs will still be limited to two scheduled jobs per study.
We’ve also added the Active Period option in non-Production environments for Audit Trail Export jobs, which will be visible with the 24R3.4 limited release.
Enablement & Configuration
This enhancement is automatically available with the release.
Learn More
Include Log Events in Event Listings, Extracts, and Reports 24R3.4
Use Case
These updates provide increased visibility of SDV, DMR, Freezing, Locking, and PI Signature in listings, extracts, and reports that use event operational summary records.
Description
Log events will now be included in event operational summary records. Due to the differences between log events and scheduled events, some fields in the log event summary will behave differently. These behaviors will be documented on the CDMS help site following the release.
These records are visible in the Event Progress Listing, SYS_EVT dataset, Standard Template: Schedule Deviation Report (V3) standard report, and any custom report based on the Event Progress Listing or Event Operational Summary report type.
Enablement & Configuration
This enhancement is automatically available in the general release.
Updated Column Names in Query Detail Listings 24R3.2
Use Case
We’ve updated column names to improve understanding of the Query Detail Listing.
Description
We’ve updated the following column names in the Query Detail Listing:
| Current Name | New Column Name |
|---|---|
| Answered Date | Query Answered Date |
| Answered By | Query Answered By |
| Closed Date | Query Closed Date |
| Closed By | Query Closed By |
Enablement & Configuration
This enhancement is automatically available with the release.
Learn More
Review: Vault Owner Access to Scheduled Jobs 24R3.2
Use Case
This feature provides Vault Owners with better visibility to all jobs within the Job Schedule area of the Review tab.
Description
Vault Owners are now able to modify jobs created by other users. They can see all scheduled jobs in the Review tab and are able to edit, delete or set the job to Run now. These include:
- Additive Review Listing
- Core Listing
- Data Export (Legacy)
- Detail PDFs
- Event Progress Listing
- Form Progress Listing
- Query Detail Listing
- Study Summary Metrics Report
- Subject Progress Listing
Enablement & Configuration
These enhancements are automatically available.
Updated Column Names in Form Progress Listings 24R3.2
Use Case
This feature improves understanding of the Form Progress Listing.
Description
The following columns have been updated in the Form Progress Listing:
| Current Name | New Column Name |
|---|---|
| SDV Override Plan | Form SDV Override Plan |
| SDV Required | Form SDV Required |
| Requires Re-SDV | Form Requires Re-SDV |
| SDV Complete | Form SDV Complete |
| SDV % | Form SDV % |
| SDV Age | Form SDV Age |
| First SDV Completion Date | Form First SDV Completion Date |
| SDV Completion Date | Form SDV Completion Date |
| DMR Override Plan | Form DMR Override Plan |
| DMR Required | Form DMR Required |
| Requires Re-DMR | Form Requires Re-DMR |
| DMR Complete | Form DMR Complete |
| DMR % | Form DMR % |
| DMR Age | Form DMR Age |
| First DMR Completion Date | Form First DMR Completion Date |
| DMR Completion Date | Form DMR Completion Date |
Enablement & Configuration
This enhancement is automatically available with the release.
Learn More
Clinical Coding
The following are new features for Coder, the clinical coding area for Vault Coder.
Coding Source for Propagate Code Action 24R3.2
Use Case
Coding updates applied due to the Propagate Code action are now clearly identified via the manual source field on the impacted code requests, regardless of the final status that is configured.
Description
When coders use the Code All Forms and Update Synonym List action to propagate a coding decision to all matching, coded Code Requests and Synonym List records, Vault will reflect these coding updates as a manual coding action. The Manual Source field is updated to Propagate Code and all previous autocoding property fields are cleared out for impacted code requests.
Enablement & Configuration
These updates are automatically available.
Column Updates to Coder Summary Page 24R3.2
Use Case
We’ve updated the Coder Summary page to provide greater visibility of Coding Query statuses.
Description
The Open Queries column will now reflect the count of queries waiting for site action. A new column, Answered Queries reflects the count of queries answered by the site, awaiting review and closure.
Enablement & Configuration
These updates are automatically available.
New Validation for Synonym List Record Approval 24R3.2
Use Case
This update improves the user experience during synonym list record approval.
Description
This release adds a new validation warning to synonym list record approval. When a user is attempting to approve a synonym list record, the action will be blocked if an active matching synonym list record already exists in the same synonym list with a different code.
Enablement & Configuration
These updates are automatically available.
Code Request Listing Filter and Column Updates 24R3.2
Use Case
In this release we are making updates to the Coder Code Request Listing filters and columns to increase usability and efficiency for users.
Description
The following updates have been made:
- The following filters will be made ‘sticky’ and once configured will persist across all coding form types within a single session:
- List View: Coding Status, Query Status
- Group View: Coding Status
- Updates to Subject Filter to show all subjects regardless of subject status. Previously, subjects with Pre Screening, In Screening, or Screen Failure status were not shown.
- A Study Country column is now available to be added to List View
- The Code Request Age (D) column label is updated to Verbatim Age (D). Additionally, sorting is enabled if the column is added to the table. The calculation logic for this field has also been updated to derive age in days as Today’s date - Last Uncoded Date, regardless of current coding status.
Enablement & Configuration
These updates are automatically available.
Coder Tools UI Update: Final State for Propagate Code 24R3.4
Use Case
This update improves clarity and consistency in Coder Tools > Study Settings.
Description
When the Coding System is set to Third-Party System in Coder Tools, the Final State for Propagate Code setting is now uneditable. Previously, the setting was editable but had no functional impact.
Enablement & Configuration
This feature is automatically available.
Imaging
The following are new features for Vault EDC Imaging, the imaging exam module for Vault EDC.
Assessments: Imaging Visibility 24R3.2
Use Case
Assessors have better visibility to the uploaded exams and imaging items within the Assessments area.
Description
When they are configured in Studio to be visible, items from a Form’s Imaging item group: Imaging Exam, Expected Modality, Uploaded Modality, Exam Date and Accession Number, can be viewed in the supplemental data section of Assessments. The Imaging Exam value is a clickable link which opens the uploaded exam in a modal window. Users can download the exam from the modal.
Enablement & Configuration
Automatically available in Studio configurations for Imaging studies.
Imaging: Vertical Scrolling for Multi-frame Navigation 24R3.2
Use Case
Usability improvements when viewing uploaded imaging exams.
Description
A vertical scrollbar is added to uploaded imaging exams which contain multiple frames. This allows users to vertically scroll through a series of frames while verifying and viewing the uploaded images. To assist with navigation, the current frame number and total number of frames displays adjacent to the image file name.
Enablement & Configuration
Automatically available for studies with Vault EDC Imaging.
Study Design & Configuration
Features in this area apply to Studio, the study design and configuration area for Vault EDC.
Comparison Rules V2 24R3.5
Use Case
The new version of Comparison Rules adds more flexibility and efficiency for programming date and datetime comparisons, enabling study designers to easily configure rules for a broader range of scenarios. This improvement significantly reduces the time and effort required for programming, unit testing, validation, UAT, and troubleshooting by giving users the ability to replace more User Defined Rules with Comparison Rules.
Description
Comparison Rules V2 introduces a new UI that allows study designers to configure rules more efficiently and with greater flexibility. All query rules comparing two date and datetime values can now be programmed as system-managed comparison rules. Key enhancements include:
- Support for comparisons between date and datetime data types, including automatic timezone handling for datetime conversions
- Allowing non-fully qualified identifiers, including floating Forms, Events, and Event Groups
- Configurable minimum/maximum setting for automatic handling of unknown values
- Comparisons between two Event Dates or Casebook Variables
- Configurable sequence numbers for repeating event groups, forms, and item groups
- Option for the rule action to target either identifier used in the comparison rule
- Ability to copy comparison rules from other studies/library collections
- Ability to rename comparison rules
- Added UI validations to display configuration errors immediately to the user
- Ability for users to inactivate and archive Comparison Rules*
Archiving a comparison rule now permanently removes it from the study, functioning more like an object deletion. This behavior is unique to Comparison Rules V2 and does not impact archive behavior for User Defined Rules.
Enablement & Configuration
This feature is automatically available for new studies. Contact Support to enable this feature on existing studies.
Additional Defaults for Repeating Item Groups 24R3.5
Use Case
Study designers can further meet study design requirements with additional defaulted items configured on repeating item groups. The new UI improves design efficiency by reducing clicks to enter values.
Description
A new UI has been implemented for selecting the default data option in the item group properties. Study Designers can select additional defaults for repeating Item Groups. The system automatically displays the available default Codelist Items and displays them in the order they appear within the Item Group. Designers can choose all values from the selected Items or choose specific values to display as the defaults.
Designers can also manually configure repeating Item Groups either by having the system auto-generate the groups and then adjusting the generated groups or by manually adding the groups. There is no limit to the number of defaults that can be designed. However, to maintain usability for site users, for each form there is a limit to the total number of items 750 items. “Total items” refers to the multiple of the repeating item group rows and columns, plus the other items in non-repeating item groups.
Enablement & Configuration
This feature is automatically available for new studies.
Importing Items
Use Case
This update enhances efficiency for Study Builders when creating item definitions.
Description
This feature enables Study Builders to create items by importing a CSV file, potentially saving hours in the study-building process.
After completing templates provided in CDMS Help, users can import files via the drag and drop interface, and preview the results. Upon import, the system validates the file’s completeness, ensuring it contains the proper columns and required values, enforcing character limits, uniqueness, and required field completion. Errors and warnings are displayed to assist with corrections. This feature complements, rather than replaces, the manual creation of items.
Enablement & Configuration
Contact Veeva Support to enable the Import Item feature.
Importing Codelists 24R3.2
Use Case
This update enhances efficiency for Study Builders when creating codelists.
Description
This feature enables Study Builders to create codelists by importing a CSV file. It complements, rather than replaces, the manual creation of codelists.
After completing templates provided in CDMS Help, users can import files via the drag and drop interface, and preview the results.
Enablement & Configuration
This update is immediately available to any user with the Design Study permission, including the standard CDMS Super User, CDMS API Read Write, and CDMS Study Designer roles.
Set Derived Rule Processing Updates 24R3.4
Use Case
Previously, Vault did not have a cleanup mechanism to fix issues caused by multiple derivation results pointing to the same derived item. The processing for Set Derived Value rules has been updated to address such rule conflicts. Conflicting derivation results can occur from changes to rule configurations, rule scope changes, inactivating and replacing Set Derived Value rules, or multiple Set Derived Value rules trying to derive a value for the same item.
Description
The updates to how Set Derived Value rules are stored and processed ensure that the derived value displays accurately in EDC based on the correct rule. To determine which result will set the value for the derived item, Vault now considers rule status and scope. Refer to the example below for more information.
Example: A Set Derived Value rule is configured with a fully qualified action (i.e. $eg.ev.f.ig.item). This rule is executed and sets derivation results for the target item as expected. Next, the same rule is updated so that the identifier that was fully qualified is now @Form.ig.item (where the item group.item are the same as what was used originally). Execute the rule again on the same casebook. Before this feature, the new rule would not override the value set by the old rule. With this enhancement, the new rule correctly updates the item’s value.
Enablement & Configuration
Auto-on.
Study Language 24R3.5
Use Case
Study Language allows Study Designers to designate a base language and locale in which the study will operate. This setting ensures all system labels, filters, buttons, and data are in the specified language, instead of the vault or user language. Study Language enhances study conduct for global studies where sponsors require sites to view and enter data in the study language and for studies that need to operate in languages that differ from the vault language.
Description
The following new Studio study settings have been added: Enforce Study Language, Study Language, and Study Locale, which are available to Study Designers as they configure the study setup. Users will see Study Language selections in the Study Design Specifications (SDS) and when running Casebook Comparisons (Difference reports) from Studio.
When the Enforce Study Language setting is set to “Yes”, the data entered, viewed, and saved will display in the selected study language and locale. The following areas will display in the study language:
- Labels buttons and filters in the site list page, casebook list page, task bar, signature pages
- Study related labels for forms, events, codelists, etc.
- Date formats and date pickers
- Change reasons
- Audit display
- Review activities: system queries and query dialogues, protocol deviations, assessments, additive review
- Listings & exports
- Snapshots
- Job Schedule page
- Detailed and Closeout PDFs
Users will be responsible for uploading translations for dynamic messages in their selected study language. In cases where translations are not available, the Vault language will be the default.
The user’s language, which is specified as part of their user account, is still utilized for application settings (areas that are not part of the study setup, like names of the tabs, search bar, etc).
When the Enforce Study Language setting is set to “No”, the vault and user’s language can still be used for any language where sites or users would need to operate in the vault language and users can still utilize translations.
Enablement & Configuration
Automatically available. Existing Studies are set with Enforce Study Language = No, and the Study Language and Locale are set to the vault language and locale
Lab Header Item Updates 24R3.4
Use Case
Minor enhancements to the LBDTC and LBSEX items provide better item property defaults.
Description
When enabling Local Labs for a study, the system-generated item for Sex (LBSEX) is defaulted with a length of 6 to match the longest code value in the SEX codelist. The system generated item for Lab Collection Date and Time (LBDTC) includes the No Future Date edit check within the properties panel.
Enablement & Configuration
Automatically available for new studies or for existing studies when the Enable Local Labs setting is Yes. Existing studies can make these changes and deploy the updates.
Casebook Validation Warning on Rules with Link Identifiers 24R3.4
Use Case
To assist study designers and help prevent rule inaccuracies, a casebook validation warning is added which checks link identifiers used in user defined rules.
Description
A warning will be displayed in Studio’s casebook validation report when a rule contains a link identifier followed by a sequence number, for example @Form/CM[2].ig_CM.CMINDC. Vault does not support ordering of repeating linked objects.
Enablement & Configuration
This enhancement is automatically available.
Study Administration
Features in this section apply to EDC Tools, a study-level administration area for Vault EDC.
User Locale Not Restricted by User Language 24R3.4
Use Case
Previously, Vault disallowed certain locales for specific languages. Removing restrictions on language and locale combinations further supports user management.
Description
The language and locale settings within CDMS User Administration are decoupled from one another, allowing the user administrator to select or import the language and locale combination needed for each user. For additional details, reference the Vault Platform Release Notes.
Enablement & Configuration
This feature is automatically available.
eSignature for VeevaID SSO Option 24R3.4
Use Case
Some sponsors or CROs prefer that their site users authenticate with SSO and eSign using their own SSO/SAML profiles.
Description
For CDMS vaults converted to use VeevaID, site users with a VeevaID security policy, can use either VeevaID or the sponsor’s or CRO’s localized single sign on (SSO) to electronically sign casebook data. The site user will authenticate using VeevaID or SSO, depending on how VeevaID is configured and which account was used to log into the vault.
Enablement & Configuration
Automatically available for vaults converted to use VeevaID and have SSO configured on the domain.
CDMS License Keys 24R3.4
Use Case
This feature helps reduce issues encountered during deployments and helps track the study’s eligibility for Production from the license key instead of the study name.
Description
All non-ELA (Enterprise License Agreement) users’ studies now require a License Key, which can be entered in a new field located in EDC Tools. Both the Set License Key and Billing Status options have been added to the More Options menu. New menu options can only be seen by non-ELA users.
Before deploying a study to Production, the appropriate Study License Key from the sales order form must be entered into the DEV Vault in EDC Tools. During casebook validation, the entered license key will be compared to the Vault’s stored license key. Users will see warnings for missing license keys when running validations in Studio prior to production deployment.
For users or studies that are not using CDB, the CDB License Key is not required and will not impact production deployment. For studies using CDB, the CDB License Key is required for the study’s data to be seen in CDB.
For full ELA Customers (EDC & CDB), all EDC and CDB studies are considered Licensed.
Enablement & Configuration
Automatically available. Users with the Manage Deployments permission can Set License Keys. Users with the Manage Study Milestones permission can Set Billing Status. Existing studies will automatically move to the new model without any impact to study activities.
Learn More
Show Deleted Queries in the Audit Trail Export 24R3.2
Use Case
Data Reviewers can now understand which queries were previously opened and acted upon before query deletion occurred.
Description
Deleted queries now display in the Audit Trail Export job output. Prior to this release, the audit history for deleted queries was only visible to Vault Admins. Queries can be deleted when a form or event is reset or marked for removal, or when a coding request is deleted because the verbatim term value was deleted.
Enablement & Configuration
These updates are automatically available.
Export Job History 24R3.2
Use Case
Previously, users could not obtain an audit trail of the job creations without contacting support. Users are now able to obtain an audit trail of job creations directly from the Job History area within EDC Tools to obtain Job History records.
Description
We’ve added a gear icon to the top right of the Job History grid which allows users to download the Job History records in either CSV or Excel format. After selecting the format, the export file will be generated. The user receives an email notification with the link to retrieve the file in the application. If the user has logged out themselves or has been logged out due to inactivity, they will be prompted to enter their credentials before retrieving the file. Example file name: $Study_Job Export_$DateTime.xlsx where the DateTime is indicated in the user’s timezone.
The following columns are included in the file in this order:
- Study
- Job ID
- Job Type
- Job Status
- Created By
- Job Detail Information
- Created Date
Enablement & Configuration
This enhancement is automatically available with the release.
Extracts: Update Subject Study Progression Report 24R3.4
Use Case
This new report updates the method used to include Event Date in the report.
Description
This release includes a new version of the Standard Template: Subject Study Progression (V4) report. This new version updates the report type so that the Event Date can be populated from the Event object rather than the Event Operational Summary object. Standard Template: Subject Study Progression (V4) is only visible to Vault Owners but can be shared with other users and roles.
We recommend that a Vault Owner or Report Administrator unshare the previous V3 standard report once the new version is shared with users.
Enablement & Configuration
This report is immediately available to Vault Owners until shared with other users.
Learn More
FTP Connection Enhancements 24R3.2
Use Case
The FTP Configuration report has been updated to include more information about the study to improve consistency in displaying study information.
Description
We’ve added a new column for Study Label to the FTP Configuration Report.
Enablement & Configuration
This enhancement is automatically available with the release.
Updates to Job Management: Output File Access 24R3.4
Use Case
This update improves consistency in user experience across EDC Tools Jobs Management.
Description
As part of job management infrastructure improvements, we are updating job file access. The Job file link contained in job completion notification emails now leads to an EDC-specific link. Additionally, all job file links will expire 60 days after a job is run.
Enablement & Configuration
These updates are automatically available.
Stamp Origin Site on Subject Move 24R3.2
Use Case
These updates provide improved support for site payments in CTMS in cases where subjects have been moved to a different site.
Description
We’ve made the following updates to the Subject Transfer/Subject Move process:
- The menu item and button labels for Transfer Subject have been updated to Move Subject.
- When selecting Move Subject, users will be required to provide a Reason for Move
- Selecting Subject is in the wrong site will:
- Remove data for the subject from the original site
- Move the subject and data to the new site
- Data will not keep a reference to the original site
- Selecting Subject changed sites will:
- Remove data for the subject from the original site
- Move the subject and data to the new site
- Retain a reference to the origin site on existing events, protocol deviations, and procedures.
- In both cases (Subject is in the wrong site or Subject changed sites), users will receive confirmation windows with additional friction to complete the action.
With this feature, we will no longer support moving multiple subjects in a single action in Production environments.
Enablement & Configuration
This enhancement is automatically available in the general release.
Clinical DataBase (CDB)
The following are new features for the CDB application, the Vault CDMS solution for data cleaning and reporting.
Availability: Clinical DataBase (CDB) is only available to CDB license holders. Contact your Veeva Services representative for details.
CDB Support for Protocol Deviations 24R3.4
Use Case
Protocol Deviations (PD) created in EDC can be viewed in Workbench and included in CDB Exports from Clinical Reporting or Workbench.
Description
As a first step to full Protocol Deviation support in CDB Workbench, we are making the data available as a system listing (Sys_PD) and as new CQL attributes. Users can save the system listing as a custom listing and include it in exports. Raw-type export definitions created after the release will automatically include the Sys_PD listing, and users can modify existing exports to include it.
The new CQL syntax allows users to create custom PD listings which can be sorted, filtered, and exported. The @PD notation, similar to @QRY, provides access to the PD attributes and reference to the related Form and Item (if applicable).
Enablement & Configuration
EDC Protocol Deviation data becomes available following a full ingestion of study data after the release.
Support for Repeating Event Group Labels 24R3.4
Use Case
Repeating Event Groups enable studies to define visit cycles only once, and allow the site to generate each cycle as needed. With this release, CQL and CDB support the override labels defined in Studio to be displayed in listings.
Description
New CQL, @HDR.EventGroup.RepeatLabel, is available for custom listings in Workbench to include the override label of an event group. This attribute will return the label for both repeating and non-repeating event groups.
The repeat label will be added to Sys_Forms, Sys_Events, Sys_ILB, and the Listing Builder. Organizations can also choose to include it in Core Listings by updating the configuration of CDB.
Enablement & Configuration
These labels are available to be included in a listing after the first full ingestion after the release.
CQL Support for New Header Attributes 24R3.2
Use Case
In the 24R3 release, we added new attributes to system listings. WIth this release, we updated CQL to support these new attributes in custom listings and the listing builder.
Description
The following attributes were added to CQL:
| Attribute Name in SYS Listings | CQL Syntax |
|---|---|
| Study.Label | @HDR.Study.Label |
| EventGroup.ExternalID | @HDR.EventGroup.ExternalID |
| Event.EventDateLastModifiedDate | @HDR.Event.EventDateLastModifiedDate |
| Event.WindowStatus | @HDR.Event.WindowStatus |
| Event.DaysOutsideWindow | @HDR.Event.DaysOutsideWindow |
| Event.ExpectedForms | @HDR.Event.ExpectedForms |
| Event.FormEntryOverdue | @HDR.Event.FormEntryOverdue |
| Event.FrozenDate | @HDR.Event.FrozenDate |
| Event.LockedDate | @HDR.Event.LockedDate |
| Event.SignedDate | @HDR.Event.SignatureDate |
We also updated the Core Data Listing Configuration with these attributes:
- Study.Label
- EventGroup.ExternalID
- Event.EventDateLastModifiedDate
- Event.WindowStatus
- Event.DaysOutsideWindow
- Event.ExpectedForms
- Event.FormEntryOverdue
- Event.FrozenDate
- Event.LockedDate
- Event.SignedDate
Enablement & Configuration
These attributes will be automatically available to be included in a custom listing written in CQL or via the Listing Builder. The Core Listing default values can be updated to include the subset of attributes in Core Listings, and as default selected in the Listing Builder.
Query Metrics 24R3.4
Use Case
We’ve introduced charts on the new Query Metrics page to provide insights into how queries are generated for a study and to answer questions like:
- Are the automated or manually created queries leading to a data change?
- What percentage of queries are getting re-queried, by which teams, or are they efficiently written to avoid time spent in discussion?
- Which sites are having trouble getting to closed queries based on query age or number of responses?
Description
There are three (3) charts provided in this release: Total Queries Generated, Closed Queries by Origin, and Queries By Site / Data Provider.
The Total Queries Generated chart is broken down into two parts:
By type (the inner circle)
- Automated by the CDMS system
- Manually created by a user
- Generated from an external source via the API
By source (the outer circle)
- EDC Rules
- EDC Manual
- CDB Checks
- CDB Manual
- External Sources
The Closed Queries by Origin chart displays a horizontal bar graph of the 10 sources with the highest number of closed queries without a data change.
The Queries By Site / Data Provider chart displays a bar graph with the total number of queries, color coded by source. A line graph displaying the average query age is superimposed on the bar graph .
Enablement & Configuration
Query Metrics charts are available to users with permission to View All CDB Query Listings in CDB Workbench.
CDB Review Comments in Export 24R3.4
Use Case
This feature allows for the transfer of relevant review information in exports.
Description
Review information will be included when a review listing is added to an Export Definition. The following new columns will be added to the export, including existing export definitions:
- Reviewed By
- Reviewed On
- Review Status
- Review Reason
These columns have been added to the end of the listing data.
Enablement & Configuration
These enhancements are automatically available with the release.
Observations 24R3.4
Use Case
Observations offer Data Managers a new way to save notes on data items in CDB Workbench for data that is mismatched, out of range, or unexpected. This enables collaboration between multiple teams in Workbench, allowing them to view values over time and record findings without losing notes if a value changes–all without writing a query to the site.
Description
Observations can be viewed in any listing where the data item resides, and is persisted even if the data value changes. Users can view, create, respond to, and close observations in any data listing. All observations and observation messages can be included in extracts.
Enablement & Configuration
Permissions to view, create, reply, and close Observations are given to the standard CDMS Lead Data Manager, CDMS Data Manager, and CDMS Super User roles.
CDB Use of Event Operational Summary 24R3.4
Use Case
Event properties from EDC that were previously calculated by CDB will now be pulled from the EDC Operational Summary object with 25R1.
Description
Event property fields (for example, Frozen, Locked, and Signed) will be pulled from the data provided by the EDC Event Operational Summary object, instead of calculated by looking at Event records.
Enablement & Configuration
This update is automatically available after the first full ingestion after the release.
CDB Export Usability Enhancements 24R3.4
Use Case
We’ve improved the user experience for CDB Workbench and Clinical Reporting exports.
Description
This release includes the following usability enhancements to exports in CDB and Clinical Reporting:
- It’s no longer possible to edit a listing from the Export UI. Instead, users can make changes in the listing itself, via CQL or the Listing Builder.
- We renamed the None type as Custom.
- The SDTM export type is deprecated for new export definitions. Existing SDTM-type exports won’t be affected by this change.
- The export properties dialog Delivery drop-down now shows if FTP connections are defined at the study level or the vault level.
- The issue log’s Listing column now lists the listing’s title.
- We removed the FIle column from the issue log.
- We increased the width of the Message column in the issue log to improve readability.
Enablement & Configuration
These enhancements are automatically available with the release.
Allow Manifest to Define Form & Item Labels and Item Names 24R3.4
Use Case
When importing third party data sources, customers can now define a label for an Item or Form which can be referenced with CQL in a listing. Additionally customers can define a different name than what is provided in the data file for an Item with the Item Name override feature. For example, an item name defined in the CSV data file called “LPANEL” can be overridden so that the Item name once imported into CDB is “LABPANEL”.
Description
Ingestion of third party and OpenEDC data has been updated to allow for Item names to have a defined override, so the system will import and display the name as defined in the manifest, instead of the header row value for that column in the data CSV file. Enhancements have been made as well to support Form and Item Labels for third data part sources, which can now be defined in the import manifest.
Enablement & Configuration
This feature is automatically available with the release.
Query Source Information: CQL & Listings 24R3.4
Use Case
Query source information identifies the system and user who created a query added to EDC or CDB programmatically or via API. This information will now be included in query listings and available to programmers in CQL.
Description
There are three (3) fields that are available with details on the origin or source of a query: system, user, and ID. These fields will be added to core Query Listings in CDB. Note that the origin user field will be blank if the query was created in EDC or CDB and will only populate if included in an API request.
CQL has been updated to allow query source user information to be included in a listing with @QRY.OriginUser, and all three query message fields with @QRYMSG.OriginSystem, @QRYMSG.OriginID, and @QRYMSG.OriginUser.
Enablement & Configuration
Core Query Listings will automatically include these new columns in the listing, including in exports. Change detection on the exports will identify these updates as a change to the Export Definition.
Study File Format API Enhancements 24R3.4
Use Case
Adding third-party data to Study File Format (SFF) API extracts allows all CDB data to be exported via API to downstream systems. The introduction of the Subject casebook version and medical coding requests tracking in incremental SFF extracts reduces the need to extract the full package.
Description
As part of the full daily extract via SFF API, third-party data ingested into CDB Workbench will now be included in the CSV folder and described in the manifest file.
In incremental SFF extracts, the Subject casebook version and medical coding requests tracking have been added to the export.
Enablement & Configuration
These features are automatically available after the release and require the 24.3 version of the API.
Visit Method Added to Core Listings Raw Export 24R3.2
Use Case
We’ve added additional event information to exports.
Description
For the Raw export type, we added Event.VisitMethod to Core Listings.
Enablement & Configuration
These new columns are automatically available. Existing exports will display a change notification and allow users to accept the update to the listings if they choose.
Calculated Fields in SYS Listings 24R3.5
Use Case
To better align with data available from the Study Data Extract (SDE), certain CDB system listings have been updated in Workbench and in the Study File Format (SFF) extract.
Description
With this release, we’ve added new columns to the following call functions, listings, and SFF extracts:
- Sys_Events:
- Event.WindowStatus
- Event.DaysOutsideWindow
- Sys_Forms:
- Form.SubmitToSDV
- Form.SubmitToDMR
- Form.SubmitToFrozen
- Form.SubmitToLocked
- Form.SubmitToSign
- Form.EventToSubmit
- Query Listings:
- Query.CausedDataChange
- Query.OpenToClose
- Query.OpenToReply
We also updated the calculation for Query Age on EDC queries to use the Last Closed Date field. This aligns with that calculation in Vault EDC.
Enablement & Configuration
These fields are automatically available with 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 Vault CDMS.
Support Duplicate PI Person Names 24R3.4
Use Case
More than one Principal Investigator (PI) could have the same name. The Person record now supports duplicate PI names for cases where different PIs have the same first and last names.
Description
The restriction for a PI’s name to be unique has been removed. Duplicate PI names are now permitted in order to support the creation of two different PIs with identical first and last names. A PI user’s name and email combination is now considered unique for the PI’s user record. Errors are no longer encountered when adding a new PI within User Administration or within EDC Tools > Sites. Within the UI and in the Site grid exports, the format of the PI’s name has been updated to First Last (email).
Enablement & Configuration
This enhancement is automatically available.
CDMS CDB Programmer Standard Study Role 24R3.2
Use Case
The CDMS CDB Programmer is a role intended for programmers who are not data managers working in CDB, primarily in TST environments, to create and deploy public listings, views, and checks.
Description
This release provides the new standard role: CDMS CDB Programmer.
The CDB Programmer role is designed to be used in Workbench in both Production and Test environments. When used alone in production environments, this role can’t modify public listings, checks, or views, but the role can test production data using private listings. This provides greater control in the production environment and avoids accidental updates to deployed listings.
When working in a TST environment, we recommend providing the user with both the CDMS CDB Programmer study role and either the CDMS Lead Data Manager or the CDMS Data Manager study roles, depending on if the user requires access to restricted data. The additional role provides the user the Public Access permission, so that they can save their work as public listings. They can also set up scheduled exports, manage key mappings of third party data, and access CDB Tools.
Enablement & Configuration
This role is available to be assigned to users immediately after the release.
Integrations
Features in this section are new integrations with Vault CDMS or enhancements to existing integrations.
Clinical Operations - EDC Connection: Event Operational Summary Record Enhancements 24R3.4
Use Case
The Clinical Operations - EDC Connection allows the transfer of EDC Event Operational Summaries for indications of SDV and DMR completion to the CTMS Subject Visit record. Before 25R1, SDV and DMR roll-ups were calculated separately by the connection. Starting in 25R1, this data will be directly retrieved from Event Operational Summary records in EDC, including data for log events, as per the EDC feature Include Log Events in Event Listings, Extracts, and Reports.
Description
Event data transferred via the Clinical Operations - EDC Connection is now retrieved directly from EDC’s Event Operational Summary objects. The existing behavior in CTMS remains unchanged. Users may notice performance improvements as a result of this enhancement.
Enablement & Configuration
This feature is automatically enabled for studies using the Clinical Operations - EDC Connection.
Safety-EDC Connection: Multiple "Safety Case Initiation Event" Forms per Study 24R3.4
Use Case
Having more than one form design for Adverse Events (AE) in EDC is a common concept to allow for variations of requested safety-relevant EDC data, for example, by study drug. Prior to this release, safety administrators could only configure one Form to initiate a safety case transfer from EDC to Vault Safety. This resulted in a need to design one comprehensive AE form to cover all potential cases.
With this release, users can map multiple Forms to the Safety Case Initiation Event form type (formerly labeled Serious Adverse Event) per study to initiate a data transfer to Vault Safety. Configuring multiple EDC forms to initiate the send of a Safety Case allows for increased flexibility in AE form design in studies and libraries.
An additional key use case for this feature is an unexpected pregnancy experienced by a trial participant. With this feature, a form collecting pregnancy information can be mapped as a Safety Case Initiation Event, which initiates a Safety Case when an unexpected pregnancy is reported.
Description
In Studio > Safety Integration > Form Configuration, users are now able to create more than one Form Configuration using the Safety Case Initiation Event form type. Note that users can still only map one EDC Form to one Form Type per Study, for example, once a Lab Tests form is mapped to a form configuration, it can’t be mapped to another.
To support this feature, we relabelled the Serious Adverse Event form type as Safety Case Initiation Event. See the Safety Integrations: Updated Safety Form Type Labels feature for details.
Enablement & Configuration
This feature is automatically enabled for studies using the Safety-EDC Connection. Configuration for a live study might result in follow-up safety messages for existing safety cases.
Safety-EDC Connection: Pregnancy Information 24R3.4
Use Case
Pregnancy information can be critical when reporting an adverse event, but it might also be required to initiate a data transfer from EDC to Safety by itself. Via the Safety-EDC Connection, Vault can now transfer safety-relevant pregnancy information either with the serious adverse event or as stand-alone information.
Description
In Studio > Safety Integration > Form Configurations, the following pregnancy-related options are available for mapping on the Safety Case Initiation Event (formerly known as Serious Adverse Event) form type:
- Pregnancy Case (AE_PREG_CASE)
- Pregnancy Occurrences (AE_PREG_INFO_GRAV)
- Number Given Birth (AE_PREG_INFO_PARA)
- Pregnant at Study Drug Exposure (AE_PREG_INFO_AT_VX)
- Last Menstrual Date (Pregnancy Case) (AE_PREG_LAST_MENSTRUAL_DATE)
- Pregnancy Conception Date (AE_PREG_INFO_CONC_DT)
- Pregnancy Due Date (AE_PREG_INFO_DUE_DT)
- Date of Pregnancy Outcome (AE_PREG_INFO_OUTCOME_DT)
- Pregnancy Outcome (AE_PREG_INFO_OUTCOME)
- Delivery Method (AE_PREG_INFO_DELV_METH)
Enablement & Configuration
This feature is automatically enabled for studies using the Safety-EDC Connection. Configuration for a live study might result in follow-up safety messages for existing safety cases.
Safety Cases (V4) and Safety Messages - E2B (V4) Reports 24R3.4
Use Case
We added the Safety Cases (V4) report to reflect the latest enhancements of both the E2BLink and the Safety-EDC Connection. These updates also address requirements for varying study languages.
We also added the Safety Messages - E2B (V4) report with operational details, for improved tracing of the E2BLink-specific message exchange.
Description
The new Safety Cases (V4) report includes all columns from the Safety Cases (V3) report, as well as the following new columns:
- Form Sequence
- Events in Case
- Date Most Recent Info In Report
- Last Send to Safety
- Last Send File Name
- Last ACK File Name
- Reporter First Name
- Reporter Last Name
- Vault Safety Case
- Follow-up Inspection Needed
- Additional Follow-up Pending
We recommend that Vault Owners unshare the Standard Template: Safety Cases (V3) report and then share instead the Safety Cases (V4) standard report with those users.
The new Safety Messages - E2B (V4) report includes all columns from the Safety Messages report, as well as the following E2BLink-specific operational columns:
- Study
- Study Country
- Site
- Subject
- Send File Name
- Ack File Name
- MDN Date Received
- ACK Date Received
- Additional ACK Date Received
- ACK Error / Details
- Additional ACK Error / Details
Enablement & Configuration
These reports will be immediately available to Vault Owners to share with other users.
Safety Integrations: Updated Safety Form Type Labels 24R3.4
Use Case
We relabelled Safety Form Type labels and SDE column headers to better reflect the new flexibility in Safety Case initiation and to increase precision with safety-related EDC data.
Description
This release updated the labels for studies using either the E2BLink or the Safety-EDC Connection:
- Serious Adverse Event to Safety Case Initiation Event
- External Labs to Test Results
- Concomitant Medication to Concomitant Medications
These label changes apply across the safety-related EDC functionality.
In the Study Data Extract (SDE), the SYS_SAFC dataset column Form Sequence of Primary SAE has been relabelled to Form Sequence of Primary Event. This change applies only when using the SDE 25R1 version. Note that this is the only change when using the SDE 25R1 Version compared to the SDE 24R3 Version.
Enablement & Configuration
This feature is automatically enabled.
EDC API
The following are new features for the EDC API. See our CDMS Developer Portal's release notes for more detailed feature information.
EDC API Features 24R3.4
This release includes the following features for EDC developers:
- Copy Form Definitions
- Casebook Design Export (CDE) Enhancements
Migration Vault
Features in this section are new features for Migration Vault.
Coding Updates 24R3.2
Use Case
This update provides improved visibility of the progress and status of migration loads with Medical Coding.
Description
We have revised the Med Coding Summary table to display both the Create and Send stage of the migration process.
The Create stage references the point at which coding requests are created. The Send stage references the point at which the migration coding requests are sent to EDC Coder. The counts in this stage are populated once the Create stage is fully complete.
Enablement & Configuration
These updates are immediately available in the general release.
Support for Lab Data Migration 24R3.4
Use Case
This feature supports the migration of lab data into a CDMS migration study.
Description
YAMLs can now be used to map lab header data to a Veeva study design. Migration Vault will migrate this mapped data. Additionally, lab data can be migrated into a study when structured in a normalized (vertical) format, with one row per lab result. After a migration, normal lab ranges will be evaluated, and out-of-range data will be flagged.
Enablement & Configuration
This feature is immediately available in Migration Vault.
YAML Builder: Rave™ Plugin Support 24R3.4
Use Case
This update provides support for migrating studies from Rave to Veeva EDC.
Description
Migration users will now be able to use the YAML Builder to create mapping files for studies originating in Rave.
Enablement & Configuration
This feature is immediately available in Migration Vault.
YAML Builder: Rave™ Support for Lab Data Migration 24R3.4
Use Case
This feature completes support for migrating studies from Rave to Veeva EDC.
Description
Migration Vault now automates YAML mapping for lab data in studies migrating from Rave. The YAML Builder can identify if a form has lab data, and if so, produce a lab YAML file as a result.
Enablement & Configuration
This feature is automatically available.