What's New in 19R1

---

We are pleased to bring you CMDS in 19R1. Read about the new features below. You can find information on enabling new features in the 19R1 Feature Enablement Details.

For additional release documentation and 19R1 release details, see About the 19R1 Release.

CDMS

---

Service Announcements

Service announcements allow users to receive a banner notification in the application when there is an upcoming change or service status that requires attention. Today, Vault Operations notifies users of maintenance and product changes via Veeva Trust, Vault CDMS release documentation, and customer success managers. With this release, Vault now also displays a banner notification with information about the upcoming event, as well as a reminder 24 hours after the event begins. Users are able to dismiss these notifications.

Data Entry

---

Relabeled “Casebooks” Tab as “Data Entry”

With this release, we relabeled the Casebooks tab as the Data Entry tab. Naming this tab Data Entry better describes the purpose of this tab. This name change does not impact any existing functionality or user access to the data entry area.

Clear Signature Action

With this release, users with permission to provide eSignatures are now able to clear their signature from the Form, Event, or Casebook. Users can clear their signature after making any mistakes while signing, such as providing a signature for the wrong subject. The Clear Signature action is available in the Form-level and Casebook-level Actions menus and the Event-level More Actions menu.

Data Entry UI Enhancements

This release included two UI enhancements for data entry users:

• Repeating Item Groups: When there are no records for a repeating Item Group in a Casebook, Vault now displays the message, “No records to display”, so that users are aware that no repeating Item Group records exist. In previous releases, Vault displayed only the Item Group header.

• System Status Messages: When adding or removing dynamic Events and Forms, Vault now displays a status message along with the loading spinner. Adding Events and Forms typically takes longer than regular page navigation and form submission, and these status message let the user know why.

Casebook Schedule UI Enhancements

This release included two UI enhancements on the casebook schedule for data entry users:

• Sort By Filter: The Sort By filter for the casebook schedule is now controlled with radio buttons. There is no functional change of how the sort works.
• New Event Button: The + New Event button is now gray. There is no functional change of how unscheduled events are added.

eSignature Enhancements

This release included several enhancements to how eSignatures are applied and stored:

• Users who have ability to apply eSignatures can now sign without having to drill down into a More Actions menu. At the form level, we added a Sign button that the user can click to provide an eSignature.
• From the casebook schedule, users can also now sign multiple Events at once, or the entire Casebook.
• Event Dates will now have a record to track if it has been signed or not, which is independent of the Event record. This allows a eSignature to be associated with the Event Date when a user signs at the Event or Casebook level. The signature status of an Event Date will be included in the signature rollup status for Event and Casebook.
• We updated the signature icon and the design of the signed form banner.

Intentionally Left Blank Enhancements

With this release, we made the following changes to intentionally left blank:

Item Intentionally Left Blank Status Rolls Up to the Item Group or Form

When a user marks all Items in an Item Group as Intentionally Left Blank, Vault now marks the Item Group as Intentionally Left Blank automatically. When all Items and Item Groups on a Form are marked as Intentionally Left Blank, Vault automatically marks the entire Form as Intentionally Left Blank. This improves consistency across Item, Item Group, and Form status. Note that the Intentionally Left Blank status does not roll down from a Form to an Item Group or Item.

Marking a Form as Intentionally Left Blank Marks all Items on the Form as Intentionally Left Blank

When a user marks a Form as Intentionally Left Blank and selects a reason, Vault automatically marks all Items on that Form as Intentionally Left Blank with that same reason selection. If any Items were previously marked as Intentionally Left Blank with a different reason, Vault updates those Items to use the same reason selected for the Form.

Intentionally Left Blank Removes Completed DMR & SDV

When a user marks or unmarks an Item or Form as Intentionally Left Blank, Vault now removes any completed Data Management Review (DMR) or Source Data Verification (SDV) reviews from that Item or Form. This helps ensure that data newly added or marked as Intentionally Left Blank receives the expected SDV or DMR review.

Data Review

---

Freeze & Lock Event Dates

In this release, users who have access to the Review tab and the ability to either freeze or lock can now independently freeze or lock the Event Date. Freeze and lock actions can be found in the Event-level More Actions menu. Users still using the Data Entry tab, previously called Casebooks, cannot independently freeze or lock an Event Date outside of locking or freezing the entire form. The Event Date is frozen or locked when the user freezes or locks the Event or Casebook.

Event & Form Tree Panel

Review tab users can now view all the Events and Forms for a Subject in a single view. Vault displays the Events and Forms in a tree view, similar to the casebook schedule in the Data Entry tab (formerly labelled Casebooks). This eliminates the need to select an Event to view what Forms are within that event.

As part of this enhancement, we removed the Previous Event and Next Event buttons. Users can access all Events for the subject Casebook in the tree view.

Continuous Form Panel

This feature enhances how Vault displays forms within the Review tab. In previous releases, Vault displayed one form at a time, and the user had to select another form for Vault to display it. With this release, the form panel now displays all Forms in an Event at once. For example, if the Visit 1 event has four forms, and the user selects one of those forms, Vault automatically displays the three other forms in the form panel. Users can then scroll up and down to view all of an event’s forms. If a user does decide to click on the form on in the form list, Vault automatically scrolls to that form in the event. Previous and next task navigation now also applies to all forms in the event, instead of a single form. Learn more about navigating the Review tab.

Query Enhancements

This release introduced minor enhancements to queries:

• We extended the query comment maximum length from 255 to 500 characters.
• System queries now indicate which rule created the query. Users can hover over the Information (i) icon in the query dialog to display the rule name.

Coder

---

Access Code Request Audit Trail from More Actions Menu

With this release, Coder users can access the Audit Trail for each Code Request from the Code Request Listing table. The Audit Trail lists the change history for the Code Request, including:

• Assigned code modifications
• Queries or notes posted
• Code Request properties changes

This allows users to view history of each Code Request without leaving the Coder tab.

Grouping Code Requests

With this release, the Coder application now groups identical Code Requests and displays them in grouped order when Group Mode is enabled in the Code Request Listing table. Group Mode is enabled via a toggle button on the Code Request Listing page. Selecting one grouped Code Request also selects all other Code Requests within its group, which can be expanded within the Listing table. When a group is collapsed, a single row on the Code Request Listing page can represent hundreds of Code Requests within a group. If the user applies a code to a group all individual Code Requests will receive the same code.

In WHODrug forms, Coder groups Code Requests by the following properties: Verbatim, Indication and/or Route, Coding Status and the Assigned Code. Note that if the application is set up to exclude Indication and Route within a form, these properties do not influence the grouping process.

In MedDRA forms, Coder groups Code Requests by Verbatim, Seriousness, Coding Status and the Assigned Code. If Coder is set up to not include SAE data, then the Seriousness property does not affect grouping.

While in Group Mode, users are not able to query or post notes on any Code Requests. Users can easily toggle the Code Request Listing table view to List Mode and then issue the query or post the note on individual Code Request.

Query & Notes Enhancements

This release included three enhancements to Coder Queries and Notes on the Listings page:

• Coders can now close queries without entering any text.
• If more space is needed to write a query, the Query text field is now expandable.
• Query and Note statuses now update in real-time on the Code Request table when users create and delete a query, or when users create, edit, or delete a note.

Coder UI Enhancements

This release included four UI enhancements to the Coder Listings page:

• Users can pop out the Coding panel into its own window and place it on a second monitor in order to have one screen dedicated to the list of Code Requests and the second screen dedicated to making coding choices.
• The Dictionary tab of the Coding panel now provides user filter and column preferences for individual forms. The Verbatim Search field is now located in the Verbatim column header.
• In MedDRA forms, the Assigned Code column now displays the LLT label without the LLT code.
• In WHODrug forms that are coded with ATCs, and specifically an ATC that doesn’t have a level 4, 3, or 3, the Assigned Code column will display the Drug Name, preceded by the ATC3 Code, ATC2 Code, or ATC1 Code, respectively.

Support for Codelist Coding Properties

With this release, the Coder Listings page now support codelist based coding properties, such as, but not limited to: the Verbatim, Indication, and Route.

Also in this release, Coder now displays the Decode value for Codelist-type Items instead of the Code value in the Coder listing page, Synonym Lists, and reports.

Reports & Dashboards

---

Enablement Change: Persona-Based Dashboards

With this release, we changed the enablement of the Persona-Based Dashboards feature from Support to Auto-on.

We also added the following new standard template reports to support the population of metrics within these dashboards:

• Standard Template: Form DMR Summary
• Standard Template: Unique CRF Listing
• Standard Template: Unique Rule Definition Listing
• Dashboard: Answered Queries
• Dashboard: Number of Enrolled Subjects
• Dashboard: Form Status (Not Completed)
• Dashboard: Query Volume per Form
• Dashboard: Open Queries
• Dashboard: Out of Range Event Total

As part of this feature, we also updated the name of the Vault EDC CRA Dashboard to Vault EDC Site Monitoring Dashboard.

Coder Tools

---

Import & Export Stop Lists

With this release, coding administrators can import verbatims to an existing Stop List or a new Stop List. They can use their Stop List from past studies in the current study by importing the Stop List. Once an existing, curated Stop List is attached to a study, a large number of verbatims can be excluded from autocoding, thereby saving time. Stop Lists can be used in conjunction with any WHODrug or MedDRA dictionary release. Coding administrators can also export a stop list’s Verbatims as a CSV file, which allow them to be copied over to a new Stop List.

Import & Export Synonym Lists

With this release, coding administrators can import synonyms to an existing Synonym List or a new Synonym List. Coding administrators can use the import feature to upload synonyms from a past study into a current Synonym List. The system validates the data in the imported file to ensure that the contents match the dictionary release and version. Coder administrators can also export a Synonym List and import the synonyms into another Synonym List.

Code without Indication & Route (WHODrug)

In this release, users can chose to not use the Indication or Route fields for coding and autocoding decisions in WHODrug based forms. If a WHODrug based form does not use the Indication or Route fields, then Coder does not display that field on the Listings page, it does not inform autocoding and suggestions generation decisions, and it does not inform how Code Requests are grouped in Group Mode. Contact Veeva Services to configure Coder to exclude Indication and Route in WHODrug based forms.

Code with ATCs (WHODRug)

In Coder Tools, coding administrators can configure the entire application or a specific study to code with or without ATCs. If an organization disables Code With ATCs, then the system no longer stores ATC codes when assigning codes to Code Requests or when storing records in the Synonym List. The system also does not show ATC columns on the Coder Listing Page’s Suggestions and Dictionary tabs. Coding administrators can choose Yes or No for Code With ATCs from both Coder Tools > Application Settings (to enable at the application-level) and Coder Tools > Study Settings* (to enable at the study-level). Once a form is populated with Code Requests, this option is locked.

Code without Seriousness (MedDRA)

Users can choose to not include the Seriousness property in MedDRA based forms by contacting Veeva Services. With this option, Seriousness is not included as a column in the Code Request Listing table or be displayed in the Code Request Properties panel. Also, Seriousness does not inform how Code Requests are grouped in Group Mode.

Autocode from Dictionary

In this release, the coding administrators can configure the entire application, or a specific study, to autocode exact verbatim matches directly from the Dictionary. Coding administrators can enable this feature from the Applications Settings and Study Settings tabs in Coder Tools. If the feature is enabled, the system attempts to autocode pending Code Requests from the Synonym List, and then it attempts to autocode remaining Code Requests that are still pending coding from the Dictionary. To be autocoded from the dictionary, a verbatim must have an exact match to the LLT (MedDRA based form) or Drug Name (WHODrug based form). This feature saves clinical coders time when a study lacks Synonym List records early on in the study.

Enablement Change: Code Request Data Export

With this release, we changed the enablement of the Code Request Data Export feature from Support to Auto-on.

Studio

---

Study Design Specifications

Studio users can now export a Study Design Specification from within Studio. The Study Design Specification is a structured Microsoft Excel™ workbook that contains worksheets for each included component of the study design. Users can also choose to include information about rules and views when creating the specification. Organizations can use the Study Design Specification as a basis for discussion, review and approval of a design, or simply as documentation of a design.

Annotated PDFs

With this release, Studio users can export PDF versions of all case report forms (CRFs) within their study. They can also choose to include annotations with design details (such as OIDs, dependent values, ranges, etc.) or data export information. Users can choose to export either all CRFs, to include all forms in a Study in the order they appear in the schedule, or unique CRFs, to include only the first instance of each form in a study. Each PDF has a structured table of contents. Organizations can use annotated PDFs as a basis for discussion, review and approval of a design, or simply as documentation of a design.

Select a Casebook Version

With this release, Studio users can select earlier versions of a study’s Casebook Definition from the Studio Actions menu to view definitions and the schedule associated with that version. Previous versions are read-only, but users can export specific versions. That XML output includes only design data for that version.

As part of this feature, we added the Edit Version Properties action to the Studio Actions menu in support of future enhancements. Users can now also hover over the Information icon (i) to view details about the current casebook version.

Text-Based Rule Editor

With this release, Studio users can access a new rule editor when creating a new rule or accessing an existing one. All the previous fields and functionalities have been integrated, with some enhancements to the way users select Rule Actions.

The new rule editor includes the following enhancements:

• Vault now autocompletes identifiers, operators, and functions as users enter their rule expression.
• Faster rule creation through new save options:
  • Use Save and New after finishing rule creation to quickly create another rule without returning to the Rules listing.
  • Use Save a copy to duplicate an existing rule.
• Easier rule debugging:
  • Vault displays all errors in the expression, including data type errors.
  • The rule editor includes visualization of Rule Bindings so that users can easily identify which casebook objects a rule affects.
• Quickly access help content:
  • Users can search available functions directly in the rule editor.
  • Users can access function-specific documentation with a single click.

Enablement

The new rule editor is only available for new studies, created after the release of 19R1. Existing studies cannot be upgraded to the new expression grammar (V2) and will continue to use the existing expression grammar (V1) and rule editor. Contact your Veeva Services representative for additional enablement details.

Enhanced Vault Formulas

This feature improves Vault Formula capabilities, usability, and performance. By utilizing new operators, new functions, and new system variables, customers can streamline formulas, perform new calculations, and more easily create their data validation rules in EDC Studio. The new formula engine provide significant improvements to performance when Vault executes formulas.

We changed some existing functionalities to make them simpler to use:

• Identifiers now start with a $ sign and each part is separated by a period (.).
• Some functions were deprecated and replaced with new operators (e.g. textEquals replaced with “=”).

Among the new features are:

• #define statements allow users to create a short name for an identifier and use it in their rule expression, instead of having to use the full identifier path every time.
• Formulas can use system variables (objects starting with an @ sign) to access objects in the current formula context.
• Rules can now access some object properties, like subject Status on Casebooks or the Name of a Study Country.

Study Update Restrictions

With this release, EDC Studio now restricts changes that aren’t supported for retrospective and prospective amendments. This prevents errors or failure during the amendment process. Clinical programmers cannot make the following changes between Casebook Definition versions:

• Changing the Name of any definition object record
• Switching between repeating/non-repeating for Forms and Item Groups
• Changing the order of Event Groups
• Updating the Event Type of any Event
• Switching between dynamic/not dynamic for Events, Forms, and Items
• Moving Events between Event Groups
• Switching Item Data Types
• Decreasing Precision and Length values
• Updating an Item to reference a different Codelist or Unit
• Changing Codelist Item Codes
• Removing Codelist Items
• Removing Unit Items
• Changing the Name of a Unit Item
• Changing a Unit Item’s Conversion formula
• Changing the Default Unit Item
• Changing the Default Data for an Item Group

If any of the changes above are required, a clinical programmer can instead create a new definition object record with the needed configuration and then remove the original record.

Hide Codelist & Unit Items

In support of the Study Update Restrictions feature, we introduced the ability to hide codelist and unit items from data entry users by selecting the Hide checkbox on their codelist and unit items. After a clinical programmer hides an item, the item no longer displays on newly created forms, but it will continue to display on any existing forms. Clinical programmers can also write rules to check for these values and add queries if necessary.

Import to Update In Progress Studies

Studio users can import a study design’s XML file into an In Progress design version. Vault then checks the imported file against the In Progress design and applies changes immediately. Allowing updates via import to existing study environments reduces the amount of user acceptance testing (UAT) studies required to validate study changes. Production studies with the Published status will still require a new casebook version to publish an imported study.

Column Display Property on Column Definitions

With this release, we added the Column Display property to Column Definitions. With the release of Enhanced Vault Formulas, column Names can no longer allow spaces or special characters, as the column Name may be referenced by a derived column expression. Clinical programmers can use Column Display to add names for their columns that include names and special characters to use during data export. When left blank, Vault defaults the Column Display field with the entry in Column Name.

Study Data Extract Notifications

When clinical programmers initiate a Study Data Extract job from Studio, they now receive a banner notification indicating that Vault has begun the job. When the Study Data Extract job is complete and Vault has created the Study Data Extract View Set Definition, Vault sends the user an email notification with a link to return to Studio.

Select Object & Field Values for Column Mappings

Clinical programmers can now select clinical objects and field values from within the Views Editor. In previous releases, users had to navigate away from Studio to Admin > Business Admin, copy private keys, and return to the Views Editor. This enhancement simplifies the flow of column creation. On creation of a new column mappings, Vault autopopulates Object with “Item (itemv) and Field with “Value (valuev)”. Users can then click to select their objects and fields from the drop-down.

EDC Tools

---

Retrospective Casebook Amendments

A retrospective amendment is a study design revision that includes revisions to historically created objects, for example, adding an Item to a Form that has already collected subject data. The Retrospective Casebook Amendment feature allows data managers to migrate existing subject data from one casebook version to another, on individual Casebooks or at the Site level. Data managers can initiate retrospective casebook amendments from the new Active Versions by Site subtab in EDC Tools > Casebook Versions. Sponsors who update a Casebook Definition version mid-study can use retrospective amendments to update study protocol, correct errors in existing Casebooks, and update input or output requirements.

For example, after a study has already begun collecting data, a sponsor may determine that the sites should no longer collect vital signs from subjects on their third visit. A clinical programmer creates a new version that removes the Vitals form from that visit. A data manager would then initiate a retrospective amendment to deploy the new version to sites. The amendment removes the Form from all Casebooks. Vault removes the entered data on that Vitals form for subjects where that data was already collected. Any new subject Casebooks will no longer include the Vitals form on the third visit.

As part of this feature, we replaced the Available Versions subtab in EDC Tools > Casebook Versions with an All Versions subtab. This subtab lists all published Casebook Definition versions in a Study, version details, and the number of sites and subjects active on that version.

Prospective Casebook Amendments

With this release, we moved the Casebook Version Update job to prospective amendments. A prospective casebook amendment is a study design revision that begins “this point forward”. Data managers can use prospective casebook amendments to apply a change to all existing Casebooks, starting at the chosen start event, without removing or updating any previously collected data. Data managers can initiate prospective casebook amendments from the new Active Versions by Site subtab in EDC Tools > Casebook Versions. Sponsors who update a Casebook Definition version mid-study can use prospective amendments to update study protocol, correct errors in existing Casebooks, and update input or output requirements, beginning at the time of change.

For example, in a study for infants, parents are asked in each visit for the name of the formula they feed to their baby. Sites could choose the formula name from a list of names, stored in a codelist-type item, Formula Name. While the study was in progress, some new formula brands were introduced. So the sponsor created a new casebook version to update the Formula Name codelist with new codelist items for the new formula brands. After a data manager applies the new version with a prospective casebook amendment, Vault adds the new formula name options to any new forms and any existing forms where a Formula Name value was not already collected. Vault does not update existing entries for Formula Name because the new formulas were not available during data collection. The prospective amendment applies only to future visits for all new and existing subjects.

Data Export includes CodelistLabels.csv

The ZIP file from Data Export jobs now includes a CSV detailing the study’s codelists (CodelistLabels.csv). This file contains three (3) columns and a single row per Codelist Item Definition (codelist_item_def__v).

• Name: the name of the Codelist Definition for the item (codelist_def__v).
• Code/Stored: the stored code for the Codelist Item Definition (code__v).
• Decode/Label: the label as displayed in the data entry area for the Codelist Item Definition (name__v) This value is translated to the end user’s selected language and locale.

Statisticians and other users of exported study data can use this file as a reference when working with exported study data.

Audit Trail Export

Vault CDMS customers can now export the complete audit trail for a given study. Users with access to EDC Tools can add an Audit Trail Export job. This job creates a CSV file for each subject in the study detailing audit trail information for the subject, and then it compresses those CSV files into a single ZIP file that users can download from EDC Tools > Jobs. Data managers can use the CSV version of the audit trail for easy review of audit information. Learn more about Audit Trail Export jobs.

User Management Enhancements

With this release, we made the following enhancements to user management in EDC Tools > Users:

• EDC Tools users can sort Users by First Name, Last Name, User Name, Security Profile, Company, and Email.
• User import is now an asynchronous process. Users receive an email notification when Vault finishes importing, and users can view results from EDC Tools > Jobs > Job History later.
• EDC Tools users can now create cross-domain and cross-vault users, granting access to the vault and the Study. Cross-domain and cross-vault users can access multiple vaults with a single set of login credentials.
• We updated the User Export CSV file so that the columns match the User Import column requirements. Now, EDC Tools users can export users from one study and import them into another, needing to change only the Site Access and Country Access values. The export CSV still includes the Last Login column, which is not required for user import.

Delete Study Data in Development Vaults

With this release, users with access to EDC Tools in development vaults (such as a User Acceptance Testing, or UAT, vault) can delete study data in that development vault. This is useful when studies undergo multiple rounds of testing. Once the study team tests a version of the study design and feels the need to start over with a iteration of the design, they can now delete the underlying data collected for the study and use the same study to test the new design.

This permanently deletes any instance of subject data. Note that permanent deletion of subject data is not allowed in studies on production vaults.

Security

---

CDMS Role by Study

With this release, we introduced a new, Application Role-based permission model to Vault CDMS. This new model is a more efficient way to grant users access to a Study. With this new model, a user can have a different role in different studies. For example, a user might be a Data Manager for a Veeofen study, but is only an Auditor in the Deetoza study. This feature introduces eight (8) new Security Profiles and eleven (11) new Application Roles:

New Security Profiles:

• Data Entry
• Data Review
• Data Manager
• Lead Data Manager
• Design
• Coder
• Coder Admin
• User Administrator

New Application Roles:

• CDMS Principal Investigator
• CDMS Sub Investigator
• CDMS Clinical Research Coordinator
• CDMS Clinical Research Associate
• CDMS Auditor Read Only
• CDMS Data Manager
• CDMS Lead Data Manager
• CDMS Study Designer
• CDMS Clinical Coder
• CDMS Clinical Coder Administrator
• CDMS User Administrator

These eight new Application Roles cannot be deleted or modified. To make adjustments, administrators can copy or create custom Application Roles.

Contact your Veeva Services representative about enabling this feature and migrating your existing users.

CTMS Connection

---

CTMS Users Open Casebooks in the Review Tab

For customers that have Vault CTMS and Vault CDMS, and have the Review tab enabled, the connection that redirects the user from a Subject in the CTMS vault the Casebook in the CDMS vault can now open the Casebook in the Review tab. To use this enhancement, an Admin in the CTMS vault must update the Web Action to point to the Review tab instead of the Data Entry tab.

---

April 24, 2019: We added learn more links to the What’s New in 19R1 release notes.