A maintenance release contains fixes for issues affecting customer Vaults in production environments. Maintenance releases can occasionally include enhancements, for example, a time-sensitive regulatory requirement. This page covers maintenance releases deployed to General Release Vaults only. We communicate 24 hours prior to a maintenance release. There may be a short service disruption during deployment. The Veeva Trust Site provides the most up-to-date information on Vault’s service status. Check this site to view the current status of Vault PODs and upcoming scheduled system maintenance.
This list only covers fixes for issues that impact 20R1 General Release versions of Safety Vaults. The list of fixed issues is subject to change until the release occurs. When we identify issues to fix in a maintenance release, we attempt to get them into the earliest release possible. Sometimes, we target a specific release but are not able to deliver a fix early enough for full testing. In situations like this, we postpone the fix for a later release and strike out the description in this list.
We number maintenance releases for Safety by appending the number of the Safety-specific maintenance release to the General Release number. The most recent Vault General Release is 20R1.0, so our maintenance releases for this version are 20R1.0.2, 20R1.0.3, and so on.
Vault frequently delivers Platform maintenance releases. Safety deploys these Platform maintenance releases at a later date, along with any required fixes to Safety. For details on Platform fixes in these maintenance releases, see 20R1 Maintenance Releases.
Last Updated: August 12, 2022
July 30, 2020
Release Number: 20.1.0.12 | Build Number: 734
| Description | Issue No. |
|---|---|
| Fixed an issue where the “Determine Due Date” action was calculating the Case Due Date incorrectly. | SAF-8501 |
July 23, 2020
Release Number: 20.1.0.11 | Build Number: 725
| Description | Issue No. |
|---|---|
| Fixed an issue where the MedDRA dictionary did not consolidate with the existing terms in the system when an older version of the MedDRA dictionary was loaded. | SAF-7424 |
July 15, 2020
Release Number: 20.1.0.10 | Build Number: 709
| Description | Issue No. |
|---|---|
| Fixed an issue where Cases in the superseded state were excluded in the generated cumulative serious adverse events for DSUR reports. | SAF-7887 |
June 30, 2020
Release Number: 20.1.0.9 | Build Number: 666
| Description | Issue No. |
|---|---|
| Fixed an issue where an error appeared when uploading an EMA E2B (R3) XML file to EVWEB and submitting the same file through EMA Gateway. | SAF-7279 |
| Fixed an issue where, when a Case contained more than one Case Assessment with the same outboundRelationship fields populated (i.e. Start and End Date, Recurrence), the outboundRelationship fields were exported in an incorrect order in the generated E2B (R3) file. | SAF-7322 |
| Fixed an issue for E2B (R3) XML expression rules for Section G where, to support the values or combination of E2B (R3) data elements, XML needed to be structured based on the populated values. | SAF-7323 |
| Fixed an issue for E2B (R3) XML expression rules for Section E where, to support the values or combination of E2B (R3) data elements, XML needed to be structured based on the populated values. | SAF-7431 |
| Fixed an issue for E2B (R3) XML expression rules for Section F where, to support the values or combination of E2B (R3) data elements, XML needed to be structured based on the populated values. | SAF-7433 |
| Fixed an issue where, when generating an ICH or EMA E2B (R3) file for a Case with a blank Gender field, the Gender field was exported as a blank nullflavor instead of being omitted from the generated file. | SAF-7500 |
| Fixed an issue where, when generating an ICH or EMA E2B (R3) file, the Start and End date fields in the Case Adverse Event record were exported as invalid E2B values in section E when these fields had nullflavors. Also, when the Case Adverse Event record contained only the End date and Duration values, the corresponding Section E data elements were exported in an incorrect order. | SAF-7502 |
| Fixed an issue where users were unable to save a Case Product when they entered a custom Dosage unit. | SAF-7550 |
June 17, 2020
Release Number: 20.1.0.8 | Build Number: 657
| Description | Issue No. |
|---|---|
| Fixed an issue where, when a Dose value was inputted without a unit, an error message did not appear and the user was allowed to save the Case Product successfully. | SAF-4712 |
| Fixed an issue where the system was automatically generating Submission records for non-SUSAR and non-SAE Follow-Up Cases. | SAF-5988 |
| Fixed an issue where an error message appeared without stating the actual cause of the error after creating a Follow-Up Case with two open Case versions. | SAF-6669 |
| Fixed an issue where a Submission record was not automatically generated for Follow-Up Cases when the initial imported Case did not have a Submission. | SAF-6672 |
| Fixed an issue where a Read-only Value field was left blank in Case Product when its Unit field was blank. Now, the system will issue an “Invalid” icon when a Unit field is left blank. | SAF-6804 |
| Fixed an issue for Follow-Up Study Cases where, to automatically create the follow-up Submission, the system required the initial Case to have a completed Submission. Now, for Follow-Up Study Cases, the system generates a Submission when the current or previous Case version is a SUSAR, regardless of the initial Case Submissions. | SAF-6834 |
| Fixed an issue where, when a dosage with invalid values was deleted from the Case Product, the user was unable to save the Case Product. | SAF-7415 |
| Fixed an issue where, when multiple dosages with invalid Unit values were inputted in a Case Product, an “Invalid” icon appears for the last dosage only. | SAF-7417 |
| Fixed an issue where reporting rules were generating additional Submissions and Distributions on Follow-Up Study Cases when the Study was not associated with those reporting rules. | SAF-7445 |
| Fixed an issue for Submission and Distribution records in Follow-Up Study Cases where a Transmission record was created for all possible scenarios (i.e. Product and Study, Registration/Country/Agency) because there were no rules to identify when a Transmission record should be created. Now, for Follow-Up Study Cases, a Transmission record is created only when a Registration exists for the Study associated with the Case. | SAF-7453 |
June 8, 2020
Release Number: 20.1.0.7 | Build Number: 602
| Description | Issue No. |
|---|---|
| Fixed an issue where, when using B.4.k.5.3 in an E2B (R2) file, product dosages were aggregated on import. | SAF-6655 |
| Fixed an issue where EVWEB XSD validation failed after selecting “Cyclical”, “As Necessary”, or “Total” for Frequency instead of a value. | SAF-6806 |
| Fixed an issue where a server error appeared when a user without permissions to read User security tried to create records on Safety objects with an api_name field. | SAF-6828 |
May 22, 2020
Release Number: 20.1.0.6 | Build Number: 570
| Description | Issue No. |
|---|---|
| Fixed an issue where cumulative case calculations were not considering the correct start date when generating aggregate reports. | SAF-6605 |
| Fixed an issue where the interval column did not include the latest New Info Date in range for PBRER Number of Product Reactions by Term for Postmarketing Sources table. | SAF-6648 |
May 20, 2020
Release Number: 20.1.0.5 | Build Number: 550
| Description | Issue No. |
|---|---|
| Fixed an issue where the audit log recorded that the system created Follow-Up Cases instead of the user who triggered the action. | SAF-6344 |
| Fixed an issue where Case Relatedness was not properly set to Not Related when Case Assessment Result(s) referenced custom Controlled Vocabulary records for the company source using E2B values 2 or 4. | SAF-6447 |
| Fixed an issue where a descriptive error message did not appear when Follow-Up Case creation failed due to a Case field referencing an inactive Controlled Vocabulary record. | SAF-6449 |
May 14, 2020
Release Number: 20.1.0.4 | Build Number: 525
| Description | Issue No. |
|---|---|
| Fixed an issue where users were unable to open links to documents or Cases from vault notifications. | SAF-5874 |
| Fixed an issue where the Expected (expectedness) fields on Follow-Up Cases did not match the field values from the initial Case. | SAF-6096 |
| Fixed an issue where after you manually changed the auto-calculated Expected field to set the value to Yes (Overriden), the system updated the Expedited field to No instead of leaving the Expedited field as-is. | SAF-6123 |
| Fixed an issue where Follow-Up Cases created from a non-expedited closed Case were being expedited. | SAF-6341 |
May 6, 2020
Release Number: 20.1.0.3 | Build Number: 497
| Description | Issue No. |
|---|---|
| Fixed an issue where you could not create a Follow-Up Case from a Case containing multiple Case Product or Case Adverse Event records with identical names. | SAF-6157 |
April 30, 2020
Release Number: 20.1.0.2 | Build Number: 454
| Description | Issue No. |
|---|---|
| Fixed an issue where, when a preconfigured Study Site had a blank Registration field, a NullPointerException error appeared when a user tried to complete the Triage task. | SAF-5620 |
| Fixed an issue where the value from the Event (Reported) - English field was not populated in section 7+13 of the CIOMS I form. | SAF-5871 |
| Fixed an issue where the value from the Event (Reported) - English field was not populated in section B.5 of the FDA 3500A form. | SAF-5872 |