What's New in 22R1
Pre-Release Date: March 28, 2022 | CDB Pre-Release Date: April 4, 2022 | Release Date: April 8 & 22, 2022We are pleased to bring you CDMS in 22R1. Read about the new features below. You can find information on enabling new features in the 22R1 Feature Enablement Details. Information on developer features (REST API) is in the Developer Portal.
CDMS
Features in this section are changes that apply to all application areas of Vault CDMS.
Standardize DateTimes in Email Notifications
With this release, Vault standardizes all dates and datetimes coming from the Casebook or other study-defined attributes (such as the Randomization Date set by the Randomization module) according to the study’s specified Standard Date Format and selection for Twelve Hour Time (Yes for 12-hour time, No for 24-hour time).
For dates, Vault uses the provided date format, or, if none is selected, the default “dd-MMM-yyyy” format. For time, Vault uses “HH:mm” for 24-hour time and “hh:mm” for 12-hour time.
Vault also displays all emailed datetimes in the site’s timezone. Prior to this release, some datetimes, such as the Randomization Date) were displayed in UTC.
Use Case
This feature standardizes the output for dates and datetimes in email notifications which enhances notification readability for users.
Enablement
This change applies automatically to all new and existing email notifications.
Enablement Change: Action UI
In 21R2, Vault Platform introduced Action User Interface (UI), a set of UI enhancements that give end-users an enhanced and more productive user experience by helping them perform frequently used actions in fewer clicks. The design is easy to learn, modern, and intuitive. With this release, this feature is enabled in Vault CDMS.
Visit the Action UI site for regular updates, webinar recordings, and more information on this collection of enhancements: https://go.veeva.com/21R2-ActionUI.
Enablement
The Action UI is automatically enabled.
Display Item Group Headers in Detail PDFs
Detail PDFs now include visual headers for non-repeating Item Groups when the Item Group has the Header Visible property checkbox selected in Studio.
Use Case
This feature makes the display of non-repeating Item Groups consistent with the display of repeating Item Groups.
Enablement
This change applies automatically for all Studies.
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.
Form Linking UI/UX Enhancements
With Form Linking Version 2, linked forms and their data will display in a new visible group below the form data. The process for linking a form to another form remains the same, but the Data Entry users no longer have to navigate to another tab to add, edit, or view a link. Instead, they can perform these actions while remaining on the same page as the form data.
Use Case
This feature makes it easier for Site users to add or edit a linked form, as linking is now performed on the same page as Data Entry.
Enablement
This feature is available to Studies using Form Linking V2. Form Linking V2 is automatically enabled for Studies created after the 22R1 release. For existing Studies (created pre-22R1), a Vault Owner must set the Form Linking Version field to “2” from the study’s Study Configuration record to enable this feature.
Item to Form Linking
With this feature, Data Entry users can link an individual item to another form. In Studio, there is a new item type called Form Link, which study builders can add to a form. When a Form Link item is added to a form, the study builder can set up to five Display Items, which are items from the linked form that display within the link item.
In Data Entry, site users can link this item to another form. After a link is created, data from the linked form will show in the display items.
Because the form link is saved on the item, the item can be queried, reviewed, and included in reports and extracts for downstream traceability.
Custom Study Roles for data entry must have the Data Entry and Edit Form Link permissions in order to link an item to a form.
Note that CDB doesn’t support Item to Form Linking.
Use Case
With this feature, users can link to a form for a specific reason, such as linking to a related medication or an adverse event. Users can also perform the same tasks as other items, such as SDV or open queries, which will force Data Entry users to link to a form.
Enablement
Item to Form linking is only available for studies on Data Model 2. In 21R3.4, this feature must be enabled by Veeva Support. With the 22R1 release, this feature will be automatically enabled, but a study designer must configure it for the Study before it is exposed to site users.
Enablement Change: Removed Ability to Opt Out of Item-level Intentionally Left Blank
With this release, we removed the ability to disable Item-level Intentionally Left Blank, to prevent issues with Item Group-level Intentionally Left Blank. As part of this change, the Item-Level Intentionally Left Blank feature is now enabled in all vaults where it was previously disabled.
Enablement
This change applies automatically. If Item-level Intentionally Left Blank was not enabled in your vault, it is now 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.
Additive Review
Additive Review allows review users to perform additional SDV and DMR tasks on Items that are set to Not Required on the subject’s assigned Review Plan.
While viewing a Casebook in the Review tab, a user can turn on Additive Review mode, select the Reason for performing additive review, and complete SDV or DMR on the chosen Items. The reason is applied to all Items that the user reviews during that session. The session ends when the user leaves Additive Review mode.
Use Case
Reviewers can take the initiative to perform extra review for training purposes, quality review, etc. and get credit for the work they’ve done outside of the review plan requirements.
Enablement
The Additive Review feature is only available to Studies using Review State Rollup V2. The Additive Review feature is enabled choosing Yes for Enable Additive Review from Studio > Settings. Once enabled, Additive Review mode becomes available to Review tab users with the Edit SDV or Edit DMR permission immediately.
Access Study Listings Jobs from the Review Tab
With this release, CRAs and Data Managers can generate and schedule the below Study Listing jobs from the Review tab. These listings will have the same data as the listings in EDC Tools, but they can be filtered by Site or by Study Country.
- Form Progress Listing
- Subject Progress Listing
- Event Progress Listing
- Query Details Listing
To access these jobs in the Review tab, the user’s study role must have the Review Tab and Manage Jobs permissions.
Use Case
This feature allows users to access the same study listing without requiring access to EDC Tools. CRAs can use these listings to see summaries at the Form, Subject, Event, and Query level for their specific sites or countries.
Enablement
This change applies automatically. Users can generate these listings Studies on both V1 and V2 of the data model, but some columns will only populate for V2 studies.
Enhancements to Medical Assessments
With this release, we renamed “Clinical Assessments” as “Medical Assessments”. Note that in this release, we didn’t update the labels of the standard roles for assessments (CDMS Clinical Assessment Reader and CDMS Clinical Assessment Editor). We also added the ability to View Summary for repeating Forms while performing an assessment.
Use Case
View Summary in the Assessments tab provides parity with the Review tab and makes it easier for assessors to view repeating data.
Enablement
This change applies automatically to all Studies.
Ability to Jump to Previous/Next Instance in Expand Log Form Layout
When in the expanded log form layout in the Review tab, users can use the up and down arrows to jump to the next or previous form instances. To use this feature, users need access to the Review tab and the View SDV or View DMR permissions.
Use Case
This feature makes it easier to navigate between forms in the Review tab.
Enablement
This feature is automatically available for all Studies.
Clinical Coding
The following are new features for Coder, the clinical coding area for Vault Coder.
Unique Terms Report
With this feature, coders will be able to generate the Unique Terms Report (UTR) to view all unique coding requests across multiple studies. This report will be available in the new Jobs section of Coder Tools to coder administrators with the Manage Jobs permission. When initiating a new Unique Terms Report job, the user will select the dictionary and study that they wish to include in the report. The following dictionaries are available: MedDRA, WHODrug, MedDRA J, and JDrug.
Use Case
The UTR counts the number of unique coding requests and the number of records matching with that request, allowing users to analyze trends and observe discrepancies in the coding data.
Enablement
This feature is automatically available.
Inactivate Coding Forms
With this release, Study Designers are able to delete Coding Configurations from the development environment, even if it has Code Requests. Users can then deploy this Coding Configuration deletion to downstream Studies (for example, UAT and Prod).
When the Coding Configuration is deleted, it is inactivated in the vault. The respective coding Form and Code Requests will be viewable in Vault Reports, but not in Coder, Coder Tools, or any Listings, Extracts, or CDB Listings. To delete the inactive Code Requests from the vault, users must run the new Delete Inactive Coding Requests job.
The Comparison Report (diff report) can detect changes if the Coding Configuration is inactivated in the source and target vaults. The Studio SDS will include this definition status.
Use Case
Study Designers now have control over the presence of a Coding Configuration on downstream Study environments.
Enablement
This feature is available automatically.
Study Design & Configuration
Features in this area apply to Studio, the study design and configuration area for Vault EDC.
Library Classifications
Librarians can now assign Classifications to the Forms in a library collection. These classifications allow them to catalog Forms by classification Type and Value. Study designers can then choose to only copy Forms from a selected Classification when copying from a library, instead of all possible Forms in the library. A classification Type contains multiple Values. For example, there is a classification type of Therapeutic Area that has values such as Asthma and COPD.
For convenience, Vault includes some preseeded Classification Types and Values for those types, including Region and Therapeutic Area. Librarians mark any of these Types or Values as Inactive, if they don’t want these classifications applied to forms in the library. Librarians are also able to add additional Values to the preseeded Types.
In Studio > Library > Forms, Librarians can classify Forms one-by-one (from the form’s Properties panel) or in bulk (from the Form listing). Vault displays the assigned classifications as columns in the listing.
The Copy From Study dialog now includes a Filter by Classification menu where study designers can filter the list of available Forms when copying into their study.
Use Case
Library classifications can help increase the adoption of standards and speed study development by only copying the Forms that apply to the Study from the library, instead of all of the library’s Forms.
Enablement
This feature is automatically available.
Use Destination as Origin when Copying into a Library
When a user copies a Study or Collection into a library, Vault assigns the destination library as the origin for all copied object records. This way, when a study designer uses that library to create a new Study or Collection, Vault will reflect the library as the origin, instead of the original study. The copy operation now also places the object records in a created state to allow tracking changes for that record within the collection.
Use Case
This feature allows the adoption of standards from Studies or other collections, providing better traceability of object standards.
Enablement
This change applies automatically.
Comparison Rules Enhancements
Study designers can now define a custom query message to use when opening a query based on a comparison rule (rule defined using the Date Comparison Configurator in Studio > Rules > Comparison Rules). Study designers can enter this text in the Query Text Override field. Rules where this column is blank will continue to use the default query message text.
We also added the following record counts to be consistent with other studio tabs:
- Total number of comparison rules
- Total number of Date comparison rules
- Total number of Datetime comparison rules
Use Case
Study designers can create rules to generate queries with informative query messages.
Enablement
These changes apply automatically available in Studies using Data Model V2. Existing comparison rules will continue to use the default query message text until a study designer enters a Query Text Override.
Track Removal of a Child from the Parent as an Update on the Parent
The Library Report now tracks the removal of a child record from the parent record (in the study schedule and form layout) as a change not only on the child record but on the parent record also. If a study designer removes an Item from an Item Group, the report shows both the Item and the Item Group as modified. In the current release, Forms don’t reflect a summary of these layout changes, and users have to leverage the comparison (diff) report to determine if there was a change to the Form by reviewing all of the underlying changes. Now, a user can get that information from the Form in the Library Report.
Use Case
This supports efficiency in the management of CRF standards.
Enablement
This change applies automatically.
New Attributes, Functions & Usability Improvements for Rules
With this release, we added the following new functions for use in rules with Expression Grammar V2:
Median()
: An aggregate function that calculates the median value of its argumentsNetWorkdays()
: A function that calculates the number of workdays between two dates or datetimesWorkday()
: A function that returns a date/datetime that is a given number of days after a date/datetime. The function returns the next available workday if the resulting date is on a weekend or holiday.
The IsBlank()
function now supports aggregate identifiers (arrays).
We also added the following data attributes for referencing in rules:
unit__v
(Item): Access the Name of the Unit assigned to the unit-type Itemtranslated_unit__v
(Item): Access the Name of the standard Unit for the item’s Unitchange_reason__v
(Item): Access the Change Reason _text for the _Item if it has been edited after submissionsubject_name__v
(Casebook): Access the Subject ID of the Subject for the current Casebook
When creating a rule, Vault no longer requires the selection of a Form in the Rule Details panel for rules that don’t require binding to a Form, such as rules only looking at Event Dates. Vault only requires the selection of a Form when the rule expression or action contains @Form
identifiers or the rule uses the Override Review Plan, Set Item Value, or Send Email rule action types.
Use Case
These functions and attributes increase the information that can be accessed via Rules, reducing the need for custom triggers.
Enablement
The new attributes and functions are automatically available for use in Studies using V2 of the Expression Grammar. The updated form requiredness automatically applies to all Studies using V2 of the Expression Grammar.
Query Scoping for Repeating Objects
We enhanced the scoping of queries when the targeted identifier has repeating parts. Vault will open the query on the Item that is actually generating the query, provided that this identifier is also present in the rule expression. Prior to this release, Vault would open the query on the first instance of the Item.
Enablement
This change applies automatically in new Studies (created after 22R1). For Studies created prior to the 22R1 release, this feature must be enabled using the Enhanced Query Scoping field on the study’s Study Configuration record.
Event Window Updates
With this release, we made changes to the method for configuring event windows to alleviate difficulty in configuring windows for repeating Event Groups (cycles).
Study designers can now choose from the following for Offset Event (as radio buttons):
- Previous Event
- Specific Event (allows users to select the Offset Event Group and Offset Event)
- None
Secondly, study designers can now override the event window configuration for Events in repeating Event Groups. This is in the updated Repeating Event Overrides dialog, accessed by clicking Repeating Event Override (Labels, Windows) in the event’s Properties panel (formerly labeled “Repeat Labels”).
With the release, we are automatically migrating existing Studies to the new model. For Events where the Event Offset hasn’t been selected, Vault will default to None. If the Event does have an assigned offset event, Vault creates a new record linking the chosen Offset Event to the Event Group containing that Event. If the Event is used across multiple Event Groups, Vault automatically selects the Event Group prior to the current event’s Event Group (and most recently, if there are multiple Event Groups with the Offset Event that occur prior to the current Event Group). For example, if the current Event Group is 501, and the Offset Event belongs to 201, 301, and 701, Vault uses the 301 event group, as it is before and most recent to 501. Entries in the Overdue Days property remain if set, regardless of the existence of an Offset Event.
As part of this enhancement, we added the Repeating Event Groups worksheet to the Study Design Specification to track configurations specific to repeating Event Groups. This worksheet has the following columns:
- Event Group Name
- Sequence
- Default Display
- Offset Days
- Day Range Early
- Day Range Late
Use Case
These changes allow users to define windows for Events within repeating Event Groups (cycles). They also reduce study development time by providing the ability to calculate the window based off of a previous Event, instead of selecting a specific Event each time.
Enablement
These changes apply automatically. Because we upgraded the configuration of existing event windows, study designers should review their configurations where an Event is used in multiple Event Groups after the release, to ensure that the windows were migrated correctly. If possible, organizations should identify these Studies prior to the release to prepare for these changes.
Studio Usability Improvements
This release includes two usability improvements for Studio:
- The User Defined Rules page no longer lists system-generated rules, including univariate rules like Future Dates, Range Checks, Required, Progressive Display, or Comparison rules.
- When executing Set Item Value rule actions, Vault no longer sets the item’s value if the Item is hidden or disabled by progressive display.
Use Case
These improvements study development time by eliminating system controlled objects from user managed maintenance screens.
Enablement
These changes apply automatically. To return to the original rule display behavior (display both user-defined and system-generated rules), create a Study Setting record named “show_system_rules” with the Value set to “true”.
Study Administration
Features in this section apply to EDC Tools, a study-level administration area for Vault EDC.
External FTPS & FTP UI Enhancements
With this release, we refreshed the UI for creating Connections to FTP servers in EDC Tools. We updated our data model for storing external connections. Vault CDMS now supports the following connection types:
- Veeva Vault FTPS: Used to send files to a Veeva Vault FTPS server
- External FTPS: Used to send files to an external FTPS server outside of Vault
- CDB Workbench: Only enabled for Workbench customers to send files to external FTP or FTPS servers
To access the FTP dialog, users need the Manage FTP permission.
For External FTPS type connections, users need their own FTPS server enabled using Passive FTPS. Users need their firewall ports open to ports TCP 21 for the control channel and 56000-56100 for the data channel. If users need a specific port range open, there is a process for submitting a request and getting security approval.
For the Veeva Vault FTPS, users need access to a Vault FTPS server with TCP ports 21 and 56000-56100 open.
To configure a CDB Workbench connection, the vault must contain the CDB application. As part of this enhancement, the process to create an FTP destination for CDB exports has changed.
Use Case
Users can send exports like Study Data Extract and Code Request exports to their external FTPS server in addition to the Veeva Vault FTPS server.
Enablement
The updated FTPS and FTP UI is enabled automatically. External FTPS connections are automatically available for qualifying FTPS servers.
SDE: Include Randomization Treatment
With this release, we’ve added a checkbox to the SDE dialog for SDE Version 22R1 to allow the inclusion of treatment information in the SDE SYS_RAND dataset. This option is only visible if users have Randomization enabled and the study is unmasked, or if the user running the job has the View Unmasked Data permission. When this option is checked, three new columns will appear in the SYS_RAND dataset, including TREATMENTNAME, TREATMENTLABEL, and TREATMENTARM.
Use Case
This feature provides more information about treatment information in the SDE for customers to analyze and ingest in their downstream programs.
Enablement
This feature is only available with the 22R1 version of the Study Data Extract job in studies where Randomization is enabled. To include treatment information in the SDE, the Study must be unmasked or the user must have the View Unmasked Data permission.
Reconstitute Code Requests Job Enhancements
This enhancement allows users to run the Reconstitute Code Requests job on all forms and select coding forms.
Use Case
This feature improves performance of the Reconstitute Code Requests job and allows users more flexibility around which forms they want to run the job for, which is particularly useful for large Studies.
Enablement
Users must have access to the EDC Tools Jobs tab and the Manage Jobs permission.
SDE: General Enhancements
This feature includes the following general enhancements for the Study Data Extract job:
- A file called csv_to_sas_log.zip will be included in the job record if a job fails.
- The Datetime in the Site’s timezone and the Datetime in the timezone of the user running the job will use SAS format DATETIME22.3 in the 22R1 version of the SDE.
- The 22R1 version of the SDE includes extended character lengths and SAS lengths for the LABID column (SYS_LABLOC and SYS_LABRANGES) and PDRES column (SYS_PD) datasets.
- The 22R1 version of the SDE includes a compressed ZIP file for SAS exports. To include a compressed ZIP file for earlier versions of the SDE, contact Support to enable SAS Artifact Compression.
Use Case
This enhancement is helpful for resolving any SAS-related issues during package generation.
Enablement
This feature is automatically available.
SDE: UI Configurator
This feature allows users to select which System Datasets, Clinical Datasets, and Custom Objects they want to include in their SDE zip file. By default, all System Datasets and all Clinical Datasets will be exported, with no Custom Objects included. If a user decides to change their selection, a shuttle will appear in the dialog where users can customize their export. This feature is only available for the 22R1 version of the SDE.
Use Case
This feature allows further customization of the SDE and helps to close the gaps with Utilities regarding the exclusion of certain datasets upon export.
Enablement
This feature is automatically available for the 22R1 version of the Study Data Extract job.
Randomization
Features in this section are new features for the Randomization module of Vault EDC.
Option to Require Login Credentials to Reveal Treatment
Users can configure in the Randomization module whether a Site requires login credentials if the Site has the Reveal Treatment permission.
Use Case
This feature is consistent with the Sponsor/Site protocols to decide whether login credentials are required.
Enablement
This option is available in Studies where Randomization is enabled.
Labs
Features in this section are new features for the Labs module of Vault EDC.
Add Analyte Name Column to Audit Trail
With this release, we added a new column for Lab Normals: Analyte Name to the Audit Trail.
Use Case
Adding the Analyte Name makes the Audit Trail more user-friendly.
Enablement
This change applies automatically in Studies where Labs is enabled.
Add Initiated by Study and by Site Columns
With this release, we’ve added the following two new columns that will show who created new Lab Locations:
- Initiated by Study
- Initiated by Site
Users can see who initiated the Lab only if they have access to the Study and Site.
Use Case
Users can direct questions regarding any new Lab Locations to the creator of those locations.
Enablement
This change applies automatically in Studies where Labs is enabled.
Add Lab Name & ID to Outdated & Updated Normals Reports
With this release, the following two columns were added to the Outdated Normals Report: Lab Name and Lab ID.
Use Case
Users can easily see which labs have outdated information.
Enablement
This change applies automatically in Studies where Labs is enabled.
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.
Study Role Enhancements
With this release, we made the following changes to standard Study Roles and their assigned permissions:
- In support of the Library Classifications feature, we added the following permissions:
- View Classification, assigned to CDMS Study Designer, CDMS Study Designer Read Only, CDMS Librarian, and CDMS Super User
- Edit Classification, assigned to CDMS Librarian and CDMS Super User
- In support of the Vault Configuration Report feature, we added the Vault Configuration Report permission and assigned it to the CDMS Super User and CDMS Deployment Administrator
- In support of the Import Change Approvals feature, we added the Approve Import permission and assigned it to the CDMS Lead Data Manager and CDMS Super User roles
- In support of the Unique Terms Report feature, we assigned the Manage Jobs permission to the CDMS Clinical Coder Administrator role
- Assigned the Manage Jobs permission to the CDMS API Read Write role
- Assigned the View Lab Locations and Normals permission to the CDMS Clinical Research Associate role
For ease of role creation, we added the following permission dependencies:
- Data Entry automatically adds Edit Form Linking
- View Casebook automatically adds View Form Linking
- Vault Configuration Report automatically adds System Tools Tab, Manage Jobs, and Reports Dashboard Tab
- Edit User automatically adds all standard tab permissions
Enablement
These changes apply automatically to standard Study Roles. Permission dependencies apply when editing or creating a new role. Note that removing a permission with dependent permissions doesn’t remove the dependent permissions.
Prevent Bulk Updates to User Email
Vault now prevents bulk updates to the Email field for Users. To edit emails, a user administrator must edit Users individually. If a user administrator imports a user import file with a modified email, Vault generates an error during import.
Enablement
This change applies automatically. Organizations can contact Veeva Support to switch this to a warning, instead of an error, allowing for bulk email changes.
Deployments
Features in this section are enhancements to deployment functionality in Vault CDMS.
Vault Configuration Report
With the Vault Configuration Report, you can generate a report (Excel™ file) containing configuration information, including the Vault Settings, Study Configurations, Roles, Change Reason Configurations, Security Policies, Report Types, Reports, and Dashboards components for a vault. The report also includes a Summary of the vault. Deployment administrators can run the Vault Configuration Report job from the new System Tools > Job History tab.
The Vault Configuration Report contains the following worksheets:
- Vault Settings: Displays the Lab Analytes per Study, Multi-Role Security, Randomization, and Workbench settings
- Study Configuration: Displays the Study Configuration details for every Study that the user has access to in the current vault
- Roles: Displays the standard and user-defined roles
- Change Reason Configuration: Displays the standard and user-defined Change Reasons
- Security Policies: Displays the password requirements, expiration period, reuse policy, security question policy, and delegated authentication via Salesforce.com (only displays information if the user who ran the report is a domain administrator)
- Report Types: Displays all standard and user-defined Report Types
- Reports: Displays all standard and user-defined Reports with the sharing settings for each report (only displays information if the user’s role has the Reports Dashboards Tab permission)
- Dashboards: Displays all standard and user-defined Dashboards with the sharing settings for each dashboard (only displays information if the user’s role has the Reports Dashboards Tab permission)
Use Case
The Vault Configuration Report is useful for tracking and documenting a vault’s configuration before and after any configuration projects.
Enablement
This feature is automatically available.
Restore Study Environments
With this release, users can download the backup of the study design for a deleted study environment and use it to restore the study design. An EDC Tools user can select the Restore action from an environment’s Actions menu. Then, they can select Restore from File in the Restore Study Design dialog and select the backup file. Note that this action only restores the study’s design. It doesn’t restore the study data. There is no change in the Restore from Environment flow.
Use Case
If a user deletes an environment in error, this enhancement will restore the study design. The Restore option is only available in a development (DEV) environment.
Enablement
This feature is automatically available.
Integrations
Features in this section are new integrations with Vault CDMS or enhancements to existing integrations.
Codelist Mapper for Safety Configuration
Study designers can use CDASH codelist codes when designing Codelist items, and a safety administrator can configure Safety Link to map those codes to the appropriate values for the E2B XML. When Safety Link generates the E2B XML file for a Safety Case, Vault translates the CDASH codes into the appropriate E2B codes, allowing the safety system to interpret those values correctly.
For example, a Study may have a codelist for Sex. In CDASH, the Codelist Code is “M” for “Male” and “F” for “Female”. In E2B, the expected Codelist Code is “1” for “Male” and “2” for “Female”.
Use Case
Study designers have more flexibility and no longer need to use rules as a workaround to use both CDASH and E2B codelist codes.
Enablement
The ability to map codelist codes is automatically available, but a safety administrator must perform the mappings before the E2B XML file is impacted.
Suspected Concomitant Medication
In some cases, a serious adverse event may be caused by a concomitant medication, instead of the study drug. This feature allows site users to indicate if a linked Concomitant Medication is just a concomitant medication or if it’s suspected to have caused an SAE (by using Item to Form Linking between the ConMed and AE forms). CDMS then records that in the Safety Case and transmits it to the safety system in the E2B XML package. Any administered study drug in the XML is then marked as interacting. Safety Link tracks this relationship and generates follow-ups as required.
Use Case
Site users can indicate if a Concomitant Medication that is linked to an SAE is suspected of causing the SAE. Then, Safety Link sends this information to the safety system in the E2B XML in G.k.1.
Enablement
To use this feature, Form Linking V2 must be enabled for the Study. Then, once the study design requirements are met, a safety administrator can configure this feature from EDC Tools > Safety Configuration.
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.
Import Manifest Builder
When preparing to import third party data into CDB, one of the major activities is configuring the manifest file that must be included with the data for import. This manifest file is a JSON (JavaScript Object Notation) file that CDB uses to configure import behavior for the specified Source, as well as to describe the data properties and required mapping. To configure an import package, a user needs to know what attributes require configuration and how to configure those attributes properly. For many data vendors, creating and working with a JSON file may be unfamiliar, and they may not know which attributes require configuration, leading to errors during manifest file creation.
To help flatten the learning curve and reduce the time required to correctly configure a manifest, CDB now includes the Manifest Builder configuration tool. The Manifest Builder is a step-by-step wizard that guides a user through all manifest file configuration options in a user-friendly interface. In the Manifest Builder, the user is presented with every import option, which they can set without needing to understand JSON.
In the Manifest Builder, users can choose to configure a new file from scratch or to import an existing file to modify. There are four (4) steps in the Manifest Builder:
- Package Configuration: Define package-level properties, such as the Name of the Study and Source, as well as how the incoming data should be matched to EDC data.
- Add Data Files: Upload CSVs for import or create CSV file templates for loading data. If the user uploads a CSV file, CDB reads the header row and automatically adds those values for use during the File Configuration step.
- File Configuration: Define all file-specific mappings, as well as the data type and properties for each column (such as Length, Format, and Precision). Available properties depend on the chosen data type. By default, CDB sets the data type to Text with “1500” for Length.
- Summary: Preview a summary of all configuration, then generate a ZIP package containing the configured manifest file and a CSV file with the header row for each file in the import package. CDB doesn’t save any configuration in the Manifest Builder, so the only way to maintain a configuration is to generate the ZIP package.
Users aren’t required to log into Vault to access the Manifest Builder. The Manifest Builder is accessible via direct link.
Use Case
The Manifest Builder provides an easier and faster way to configure a manifest file correctly. This helps streamline the setup for importing from new data sources into CDB.
Enablement
This feature is automatically available. Users aren’t required to log in to Vault to access the Manifest Builder.
Import Change Approval
To ensure that data being imported into CDB doesn’t change from the approved format and structure, CDB detects any changes to package configurations from one load to the next for each third party Source.
If the system detects changes in configuration at the package, file, or blinding level, or changes in the CSV file structure, CDB pauses the import process. The package isn’t processed and enters the Paused status until a user with approval rights either approves or rejects the package. If the user approves the package, CDB records the approval reason and imports the data package. Once a package is approved, CDB notifies subscribers to the approved change via email. CDB displays a change indicator on all associated Listings and Views. Users are able to dismiss this indicator and download the form change log for any listing or view. If the user rejects the package, CDB records the rejection reason, marks the package as Rejected, and assigns it the Not Imported status. CDB then reverts to the last successfully imported data package for the Source.
When a package is in the Paused status, all other uploaded packages for that same Source enter a queue and will wait for the paused package to be approved or rejected. Once the paused package is approved or rejected, CDB skips to the last queued package for processing. Any packages between the last paused package and the last package in the queue aren’t processed. For example, if “Package 1” is uploaded and paused, then packages 2-5 are uploaded while “Package 1” is still in the Paused state, once “Package 1” is approved or rejected, CDB will skip to “Package 5”, leaving packages 2-4 unprocessed.
For the first uploaded package in a new Source, CDB automatically applies the Paused status, and a user must approve or reject that first package before any data from that Source appears in the system.
For packages requiring approval, Workbench now includes a Package Detail panel with tabs for Differences and Associated Objects. The Differences tab displays the changes in the manifest between the current and previous packages. Users can review the previous and current value of the changes that they’re approving. The Associated Objects tab displays the Export Definitions, Listings, and Views that the changes in the package may potentially impact.
To approve or reject an import package requires the Approve Import permission, which is by default assigned to the standard CDMS Super User and CDMS Lead Data Manager study roles.
Use Case
Allowing the system to automatically detect changes in an import package helps prevent accidental or unintentional changes from occurring. For example, a change in the blinding configuration can potentially unblind a study. Requiring approval prevents changes being applied before stakeholders are aware and able to address needed downstream updates.
Enablement
This feature is automatically enabled.
Export Change Detection & Updates
An Export Definition consists of Export Listings, that are snapshots of the parent listings. When a parent listing is updated, in some cases, the export may become out of sync with the parent, leading to outdated listing structure in export packages. For example if upstream, a custom listing design was updated, any Export Definitions that reference that custom listing will still reflect the original listing design. If the CQL is modified for an Export Listing, that listing is also considered impacted, or out of sync, with the parent listing.
With this feature, CDB flags Export Definitions that have been impacted by changes. CDB provides a quick filter to easily narrow the export definition list to only those that have been impacted. When a user opens an Export Definition, CDB shows an indicator on Export Listings that are impacted by changes. Users can use the quick filter to display only the impacted Export Listings. The impacted flag indicates that the export listing’s CQL is out of sync with its parent listing’s CQL. Users can sync select Export Listings with their parent listings, or in bulk as a batch action. Once synced, CDB removes the impacted flag from the listing. Optionally, users can review the differences between the two CQL statements without navigating away from the Export Definition.
Use Case
This feature allows users to easily identify and sync the Export Listings that have been impacted by changes to the CQL of their parent listings, reducing the possibility of outdated data sets in export packages.
Enablement
This feature is automatically enabled for Export Definitions created after this release. This feature is unavailable for Export Definitions created prior to the 22R1 (April 2022) release.
New @HDR & @Form Attributes
With this release, we added the following new attributes for CQL:
@HDR.Subject.Arm
@HDR.Subject.Cohort
@HDR.Subject.Substudy
@HDR.Subject.EndOfStudyDate
@HDR.Subject.EndOfTreatmentDate
@HDR.Subject.EnrolledDate
@HDR.Subject.InitialConsentDate
@HDR.Subject.LostToFollowUpDate
@HDR.Subject.RandomizedDate
@HDR.Subject.ScreenedDate
@HDR.Subject.ScreenFailedDate
@HDR.Subject.StartedFollowUpDate
@HDR.Subject.StartedTreatmentDate
@HDR.Subject.WithdrawnDate
@HDR.Event.Version
Enablement
These CQL attributes are automatically available.
Migration Vault
Features in this section are new features for Migration Vault.
Casebook Version Limit Validation
Migration Vault now prevents users from performing migration activities on Studies that have Sites spread across more than two (2) distinct casebook versions.
Use Case
This feature ensures that Studies are configured appropriately in order to support migration-related activities.
Enablement
This feature is automatically enabled in Migration Vault.
SDV, ILB, Frozen, Locked & Signed Attributes
Users are now able to mark source data with the following attributes:
- SDV (Source Data Verification)
- ILB (Intentionally Left Blank)
- Frozen
- Locked
- Signed
Use Case
This feature reduces the amount of manual, post-migration efforts needed for the relaunch of Studies by appropriately marking subject data with these attributes during migration load.
Enablement
Support for the consumption of these attributes is automatically enabled in Migration Vault. Migration developers must create a new “attributes.csv” file (to be loaded alongside the Mapping Configurations) to use this feature.
Source Stamping
With this release, Vault now tracks the provenance of migrated records with the Migrated value on the Source Type field.
Use Case
This feature allows for further future enhancements to support enhanced reporting, rules execution, amendment execution, and various additional use cases.
Enablement
This feature is automatically enabled in Migration Vault.
Support for Migration of Code Requests
Migrated Studies now support the creation of Code Requests and ingestion of the assigned Codes from the third party EDC and Coding systems as part of the load process.
Use Case
This feature reduces the amount of manual post-migration efforts needed from the medical coding team in order for Studies to be relaunched by appropriately creating the Code Requests and filling in the assigned Codes received from the source data, as well as ensuring that the assigned codes are Current in the assigned Dictionary Released.
Enablement
This feature is automatically enabled in Migration Vault. Migration Developers must make an update to their medical coding dataset mapping files in order to support this feature.
Support for Migration of Studies Using Safety Link
Migrated Studies now support the enablement of Safety Link integrations as part of the migration process.
Use Case
This feature helps ensure that migrated Studies are appropriately supported by Safety Link and won’t create duplicate cases or other undesired outcomes as a result of standard, post-migration user activities.
Enablement
This feature is automatically enabled in Migration Vault.
View Pending Records
Migration developers can now view counts and more information about records that are in the Pending status when loading data.
Use Case
This feature helps users better understand why certain records remained in the Pending status during the migration load process in order to correct them and successfully perform their study load.
Enablement
This feature is automatically enabled in Migration Vault.