Validata Fall 2023 RP2

Last updated
Save as PDF

Platform Matrix

This section contains only updated information for Fall 2023 RP2. For the detailed platform matrix refer to the Fall 2023 Platform Matrix here (latest release where the platform matrix was updated).

Compatibility with Other Model N Products

Product	Version
Model N UAM application	Fall 2023 RP1

Note: You must install the Hotfix patch available in the following location which is mandatory for the RC-UAM integration: https://mnipdbuilds1.modeln.com/download/mn/builds/pdhotpatches/modeln/Fall2023_RP1_RECLS-99954.tar.gz

Enhancements

Validata 340B Vigilance Sub-Module Enhancements

Integration with BRG for 340B-related validation and reprocessing

Jira IDs: VD-15476, VD-15790 and VD-25338

Note: Only the pharma manufacturers with a valid license in place for the 340B Vigilance sub-module can leverage the features described in this section.

The existing 340B Vigilance add-on submodule contains meaningful features meant to mitigate revenue leakage as it relates to the 340B Pricing Program and payments classified as Duplicate Discounts. As part of the Fall23 RP2 release, these features were further extended by implementing a direct and seamless integration with Berkeley Research Group/340ESP (BRG) to access and utilize definitive 340B Rx transactions that BRG has collected on behalf of a manufacturer. This integrated process and associated validation is only available to manufacturers who have a 340B Vigilance license and also would require a manufacturer to have a relationship with BRG based on 340B policies that lead to definitive 340B Rx submission by Covered Entities and TPAs.

This feature works by including the 340B Duplicate Discount Rule Set execution against inbound Rx utilization data, whether it be from Commercial, Medicare Part D, Medicaid, or TriCare segments, within the Validation Set executed against these utilization data submissions. The validation triggers an execution of a process that connects to BRG and retrieves the collected definitive 340B Rx data and performs process steps against the utilization data submission and performs a match step. The result yields matches that are translated to an error code against the impacted Rx lines utilizing the configured severity based on the existing normal Validata setup. A dedicated Error Code and associated aligned NCPDP Reconciliation Reason Code enables transparent error identification and ‘RD’ level reporting.

For more details about the 340B Duplicate Discount Rule Set, see 340B Duplicate Discount Rule Set & Execution. Refer to the List of Reconciliation Reason Codes sheet to view the available Reconciliation Reason Code cross-reference to the Validata Error Codes.

Building upon the BRG automated integration capability included in Fall 23 RP2, an additional feature has been added to enable ongoing reprocessing of the Duplicate Discount validation related to BRG. This feature helps mitigate the timing differences between quick-submitting PBMs and ongoing data collection changes within the 340B Rx data by BRG. For example, monthly rebate data for ESI and Ascent is available on the first day of the month following the rebate period and needs to be processed and paid within 30 days. BRG generally has 45 day submission terms with the Covered Entities and TPAs submitting definitive 340B Rx data and, regulations permit the identification of an Rx as 340B for a year after the Rx was dispensed. This means that 340B Rx data impacting the rebate period being process for ESI and Ascent may arrive after the manufacturer needs to complete the validation process in order to complete the rebate payment on time. To avoid the situation where Rxs get paid/remain paid to the PBM even when revised 340B Rx data is available, this reprocessing feature permits a configurable ‘re-checking’ that will react in an agile manner to updated BRG 340B Rx data. For Rxs that have already been paid, if a later finding identifies a match to the 340B Rx data, a reversal is created using Validata’s existing reversal framework to enable the user to reverse out the previous units and pull back rebates as an adjustment within a future processing period. Likewise, if an Rx line was omitted from rebate eligibility because of a match to the 340B Rx content and later that Rx was updated to no longer be 340B, the re-processing capability will identify it and, assuming the associated error was the only reason for its exclusion, can permit the ESI/Ascent Rx to now be paid, also as part of the existing reversal process.

For more information pertaining to the configuration and execution of the 340B reprocessing, see the following documentation resources: 340B Reprocessing Configuration and Viewing Reversals Lines in the Non-Coverage Gap Submission.

To integrate the Validata application with BRG, the 340B ESP Processor must be deployed with Flex-Validata. The following three new properties have been added to the jboss/install.properties file which allows the system administrator to 340B ESP Processor in the Validata application:

validata.brg.bin.cmd
validata.brg.token
validata.brg.manufacturer

For more information about configuring the ESP Processor properties, see the Validata Installation Guide.

For manufacturers who already utilize a custom validation and error code to identify matches to BRG 340B Rx data and will migrate to the expanded 340B Vigilance product out-of-the-box, a tool has been developed to optionally permit the conversion of their historical results, validation history, and severity settings from the custom error code reference to the new OOTB error code. This data conversion can be performed as part of the deployment or upgrade process when deploying the Fall 23 RP2 or later version. The Model N application implementation team will execute the migration script.

For more information about the error code migration script, see Convert error code.

Core Product Enhancements

Enhanced reversal line migration logic

Jira ID: VD-23213

When the Non-Coverage Gap submission with reversal lines was migrated from a version prior to Fall 2023 to the Fall 2023 release, on the Reversals list table, the Reversal Status column and the status value were populated incorrectly. Now, with this enhancement, the Reversal Status column value is displayed correctly as per the new Submission workflow.

In the pre-migrated version, if the Reversal Status value for a line was 'Exported', the post-migration Reversal Status value should be populated as 'Published'.
In the pre-migrated version, if the Reversal Status value for a line was 'Cleared', the post-migration Reversal Status value should be populated as 'Skipped'.
In the pre-migrated version, if the Reversal Status value for a line was ‘Pending’, the post-migration Reversal Status value should be populated as 'New'.

For the migrated Submissions, when the reversal lines are published to create a Submission in the Payer application only the lines with a Reversal Status value as ‘Published' should be included. The 'Skipped’ lines should not be included in the Published Reversal to the Payer application.

Enhancement of Reversals workflow

Jira ID: VD-23140

When a Submission is validated using a COB validation Rule Set, after validation completion when a utilization line is identified as a reversal and has a ‘Published Status’ value as ‘Not Published’, then the respective utilization line is not a valid reversal, hence the Reversal Action column should be disabled. The Validation Analyst should not have the capability to Accept, Skip, or Publish the line when the ‘Published Status’ column value is ‘Not Published’ for a reversal line. With this enhancement, the Reversals functionality has been updated to be more in-line with the intended definition of a reversal. When a utilization line is identified as a reversal and has a ‘Published Status’ value as ‘Not Published’, the Reversal Status column is displayed as New, and the Reversal Action column is in read-only mode.

When the Validation Analyst Publishes the Submission and the reversals line’s ‘Publish Status’ value is updated to ‘Published’, then the respective line is a valid reversal line and the Analyst can proceed with updating the Reversal Action as Accept or Skip. For more information about viewing and managing the Non-Coverage Gap reversal lines, see Viewing Reversals Lines in the Non-Coverage Gap Submission.

Change of the default value for the Include backbills in summary option

Jira ID: VD-26130

In the Fall 2023 release, in the Publish options drawer, Backbill details section, the default configuration for the Include backbills in summary user input was set to Yes. When publishing a Non-Coverage Gap Submission, if the Analyst does not remember to set this option to No, the backbills will be consolidated into the current Submission period, which will result in loss of detail on account of data when publishing the lines from Validata to the Payer application.

With this enhancement, the default configuration for the Include backbills in summary user input has been set to No to not include the backbills in summary so that the Analyst should not have to remember to change the default configuration when publishing the lines to the Payer application every time. For more information about Publish Submission, click here.

Coverage Gap Sub-Module Enhancements

Ability to export/download Coverage Gap Submission invoice file

Jira ID: VD-23846

With this enhancement now the Validation Analyst can export the invoice file lines from a Coverage Gap submission, and the exported file can be uploaded manually into the Flex RM application. The Analyst can download the Coverage Gap invoice file in .txt format using a Coverage Gap Invoice active Mapping Set option. Within the Coverage Gap Submission overflow menu, the Export invoice file option will be enabled and selectable only when a Coverage Gap Submission contains an invoice file. When a Coverage Gap Submission does not contain an invoice file, the Export Invoice File option remains read-only.

For more information about exporting/downloading the Coverage Gap Submission invoice file, click here.

Ability to add dispute return or dispute resolution files to a Coverage Gap Submission even though the Status of the Submission is completed

Jira ID: VD-23826

In the previous release, the Analyst had the ability to follow the dispute process for the data lines when there is still time allotted in the Days to Dispute header information or the current date has not surpassed the Dispute Due Date. Once the Coverage Gap Submission status is marked as Completed, the Analyst cannot add the dispute return/dispute resolution files. Sometimes the TPA administrator may share the dispute return or the dispute resolution file after the Days to Dispute is completed. To mitigate such a scenario the Analyst must have the ability to upload dispute return/dispute resolution files after the Coverage Gap submission has reached the status of ‘Completed’ (the current date surpasses the Dispute Due Date or all lines have reached a status of ‘Upheld’).

With this enhancement, now the Validation Analyst can upload dispute return/dispute resolution files after the Coverage Gap Submission has reached the status of ‘Completed’ but cannot perform additional dispute actions on the data lines. When the dispute return/dispute resolution files are added to the Coverage Gap Submission, the KPI values are displayed on the Overview tab Process and results overview section, and the Data lines are updated resulting from the file upload.

For more information about the Coverage Gap Dispute Process, click here.

Help Documentation Access

SSO integration for accessing the help documentation

Jira ID: VD-21980

Effective with the Fall 23 release, the Validata help documentation was centrally presented in the Model N helpcenter portal. When accessing the helpcenter within the Validata application from all screens using the help menu from the header bar in the upper right, the users were required to enter the login credentials. With this enhancement, the helpcenter access within the application has been bypassed using SSO authentication. Users can navigate to the documentation resources in Helpcenter through the Validata application without entering the sign-in credentials.

Fixed Issues

Issue ID	Component	Issue Title	Description	Test Impact
VD-25627	Submissions	In the New Submission creation wizard, Header details tab, Validation automation section, in the Validation Set drop-down list, the validation sets options were listed randomly without any sorting order.	In the New Submission creation wizard, Header details tab, Validation automation section, in the Validation Set drop-down list, the validation sets options were listed randomly without any sorting order. This issue occurred due to a coding gap as the listing of the Validation options in the Validation Set drop-down list in the new UX was not in sync with the older UX. This issue has been fixed by listing the Validation Sets in alphabetical order based on the name, followed by the version to enhance the usability of the Validation Set drop-down list.	Within the Submission header section, open the Validation Options drawer. Verify that the validations set are listed in ascending order based on the name, followed by the version in the Validation Set drop-down. In the New Submission creation wizard, Header details tab, Validation automation section, in the Validation Set drop-down list, verify that the validations set are listed in ascending order based on the name, followed by the version.
VD-25626	Submissions	In the Mapping Set drop-down list, the Mapping Set names were listed randomly without any sorting order.	When creating a New Submission, in the File Selection page, in the Included Files table, in the Mapping Set column drop-down list the Mapping Set names were listed randomly without any sorting order. This issue occurred due to a coding gap as the listing of the options in the Mapping Set drop-down in the new UX was not in sync with the older UX. This issue has been fixed by listing the Mapping Sets in alphabetical order based on the name followed by the version to enhance the usability of the Mapping Set drop-down list.	Verify that the mapping sets are listed in ascending order based on the name, followed by the version in the Mapping Set column drop-down list.
VD-25289 VD-21811	Submissions	A blank value was displayed for the Status field when the user clicked the tooltip icon in the Filters Applied field.	In the Submission workflow pages (Submissions list, Line Level Details list, Data Lines list etc..) on the list tables when the user applied a filter for viewing the rows with a filtered status value, in the Filters Applied on clicking the tooltip icon, a blank value was displayed for the Status field in the listed details. This issue occurred due to a coding gap as the property was not included in the Filter-Saved Searches popover component to display the Status value. This issue has been fixed by adding the missing property to display the Status value in the Filter Saved Searches popover component.	Apply multiple filters on the list tables in the Submission workflow pages (Submissions list, Line Level Details list, Data Lines list etc..). Verify that on clicking the tooltip icon in the Filters Applied field, the popover component is displaying all details related to the applied filters.
VD-24305	Submissions	The Line Status was displayed incorrectly when the Submissions were migrated from a version prior to Fall 2023 to the Fall 2023 release.	When the Submissions were migrated from a version prior to Fall 2023 to the Fall 2023 release, the value for the Line Status column was not displayed correctly for the utilization lines, when the line's error code severity level was manually overridden before migrating. Instead of displaying the Line Status value as Override Included or Override Excluded, it was displayed as Included/Excluded. This issue occurred due to a coding gap when the line was manually overridden in the transaction items table after the last validation run, the Line Status was not retrieved correctly post-migration. This issue has been fixed by creating a migration script to fill in the manual override flag field to capture if any overrides occurred in the transaction tables after the last validation, for both Coverage Gap and Non-Coverage Gap Submissions.	Verify that when the line's error code severity level was manually overridden before, post-migration the Line Status column value is displayed correctly as Override Included or Override Excluded.
VD-25399	Submissions	An exception occurred when the user performed a sort on the Comments column on the Submissions list table.	On the Submissions list table, when the user clicked the Comments column to sort the column data, an error message was displayed on the user interface and the user was unable to proceed with this action. This issue occurred due to a coding gap as the API call to sort the Comment column was not established. This issue has been fixed by updating the API request to allow sorting and filtering for the Comment column.	Verify that, on the Submissions list table, when the user clicks on the Comment column header, sorting is applied to the rows and no error message appears.
VD-25744	Submission List	An incorrect value is displayed in the % Excluded column in the Submissions list grid.	When the Submission was created and validated, although the validation result excluded a small quantity of utilization lines, on the Submission list grid in the % Excluded column a Zero (0.00%) value was displayed. The correct percentage of the excluded lines was not populated. This issue occurred due to a coding gap when a Submission contains a large number of lines and only a few lines were excluded. In those Submissions, the excluded % value is a long fraction. When populating the percentage value, the application shows the value in 2 digits after decimal points. For long fraction values, when displaying 2 digits after decimal points, it was shown as 0.00%. This issue has been fixed by increasing the accuracy to display decimal points as 0.01% and inserting a value formatter to show a less than symbol before the % value, for example <0.01%.	Verify that when utilizations are excluded, on the Submission list grid in the % Excluded column the excluded percentage value is populated correctly. When the percentage of exclusion is a long fraction, verify that a less than symbol is prefixed to the value, which indicates the percentage excluded is less than the decimal point presented.
VD-20914	Submission Details	The username value was populated rather than the user’s first name and last name for a few user interface components	On the Submission workflow, for a few user interface fields like Last Updated, Created by, Deleted by etc.. the username value was displayed instead of the user’s first name and last name. This issue occurred as the username was stored in the audit column that was referenced to retrieve the first name and last name of the user to populate in the Last Updated, Created by, Deleted by, etc. fields on the user interface. This issue has been fixed by populating the user's first name and last name instead of the username value in the Last Updated, Created by, Deleted by etc. fields. In the absence of the first and last name of the user, the user name is populated.	Verify that the correct user name value is populated on the various Submission workflow pages.
VD-25463	Validations	Reimbursement Amount and Invalid Check Digit Validations were missed in Fall 2023.	The Reimbursement Amount validation and Invalid Check Digit validation introduced in the Spring 2023 release were missed in the Fall 2023 code line. This issue occurred due to a coding gap as the Reimbursement Amount and Invalid Check Digit validation introduced in a previous release were not ported to the Fall 2023 code line. This issue has been fixed by including the missed Reimbursement Amount validation and Invalid Check Digit validation to the Fall 2023 code line.	Verify that: The Reimbursement Amount validation is accessible and executes accurately without any errors. The Invalid Check Digit validation is accessible and executes accurately without any errors.
VD-21430	Delete Submission	Update the delete submission popover name	When deleting a selected Submission, the delete confirmation popover displayed the header text as “Delete submissions”. To improve the user interface usability purpose, the header text has been changed to display “Confirm delete”.	On the Submission list table, click the delete option to delete a select Submission. Verify that on the popover the header text is displayed as “Confirm delete”.
VD-26511	Non-Coverage Gap Submission	Contract ID values in the Publish drawer input filter section are missing when a Submission contains more than one utilization file associated with more than one Contract ID.	When a Submission contains more than one utilization file and more than one Contract ID is aligned with the aggregate volume of utilization lines, and when in the Publish drawer, not all Contract IDs are listed in the Contract filter section, hence the user was unable to publish the Submission by including a Contract ID. This issue occurred due to a coding gap where the distinct contracts from the utilization files/lines included in the Submission were not retrieved in the Contracts filter section. This issue has been fixed by tuning the query to fetch the distinct Contracts from the utilization lines included in the Submission and list them in the Contracts filter section.	Verify that Contract IDs are listed in the Contract filter section when a Submission has more than one utilization file and you can select a Contract ID to publish the Submission.
VD-25401	Non-Coverage Gap Submission Line Level Details	View Error Overrides and Override Line Status options were enabled for the users even though the access rules were not defined for the user.	An exception occurred when the user clicked the View Error Overrides and Override Line Status on the Non-Coverage Gap Submission, Line Level Details tab page. This issue occurred because the View Error Overrides and Override Line Status buttons were enabled for user who does not have permission to perform these actions. This issue has been fixed by disabling the action buttons on the user interface to which the respective logged-in user does not have the authorization to perform.	Verify that when the logged-in user does not have access to perform View Error Overrides and Override Line Status and respective buttons are disabled on the user interface.
VD-25745	Non-Coverage Gap Submission Line Level Details	Technical syntax was displayed on the Manage Details drawer	When the Manage Details drawer was opened from the Non-Coverage Gap or Coverage Gap Submission header section, a Technical syntax was displayed instead of the user-readable text header for the Contract details section. This issue occurred due to a coding gap. The technical syntax was populated instead of the user-readable text header name when it took a longer time to retrieve the header name due to slow internet bandwidth. This issue has been fixed by removing the duplicate technical syntax for the Contract details header and introducing a method to wait for the Manage Details drawer to load before showing translated technical syntax.	Verify that in the Manage Details drawer, the correct user-readable text is displayed for the header labels.
VD-22364	Non-Coverage Gap Submission Line-Level Details	An exception occurred when downloading the Non-Coverage Gap Submission Line Level Details list table rows	When downloading the Non-Coverage Gap Submission Line Level Details list table rows, an exception was thrown when the number of rows on the table was large. This performance issue occurred when the number of rows on the Line Level Details list table was large and when performing row download action, it reached the upper cap of memory and CPU on processing. This performance issue has been fixed by performing query tuning and optimizing memory during the download process. Note: On the Line-Level Details list table when there is a large number of rows and attempting to download as an XLS format, an exception may still display and is being addressed in an upcoming Hotfix (HF).	On the Line Level Details list table when there is a large number of rows, verify that the downloading rows is completed successfully in CSV File Format.
VD-25522	Non-Coverage Gap Line-Level Details	An exception occurred when doing an undo action for a Line-Level Error Severity Override.	In the Non-Coverage Gap Submission, in the Line Level Details list table, when doing an undo action for a Line-Level Error Severity Override, an error was displayed. This issue occurred because, in the UAM YAML (programming language) Utility, the UNDOOVERRIDE was missing in the transactionRecord and transactionRecordCGData resource. This issue has been updated by adding UNDOOVERRIDE scope in the transactionRecord and transactionRecordCGData resource in the AM YAML Utility.	For a Non-Coverage Gap Submission, in the Line-Level Details list table, override the error severity level for a line then undo the override. Verify that the undo action is completed successfully.
VD-24471	Non-Coverage Gap Submission	When performing a data grid download from the Exports grid, the Options column and its details were not included in the file.	On the Non-Coverage Gap Submission, Exports grid, when the user downloaded rows to an Excel or CSV file, the Options column along with its relevant details was not included in the downloaded file. This issue occurred due to a coding gap as the Options column was not included in the view and also in the graphQL query. This issue has been fixed by adding the Options column to the view and graphQL query.	Verify that the Options column along with the relevant details is available in the downloaded file.
VD-21397	Non-Coverage Gap Submission Publish	Definitions of the acronyms for the Publish Options were not populated in the Publish drawer.	In the Non-Coverage Gap Submission, Publish drawer, in the Publish options user input, the definitions of the acronyms were not displayed. In the Publish options user input, previously only the Publish option acronyms, such as CP, CPP, etc., were listed. Now, with this fix the definition has been added next to acronyms which specifies what the publish option means. For example, CP stands for Contract/Product, and CPP stands for Contract/Plan/Product.	In the Publish drawer, Publish options drop-down list, verify that the acronyms along with the definition text are listed.
VD-22926	Non-Coverage Gap Submission Reversal	On the Reversals list table, the Reversal Status and Reversal Action columns were not reset when the line's Publish Status was changed to Published	On the Reversal list table, when the reversal line's Publish Status was changed to Published, the value for Reversal Status was not changed to New, and the Reversal Action drop-down was read-only state This issue occurred due to a coding gap where the Reversal Status and Reversal Action columns were not refreshed when the Publish Status column was updated. This issue has been fixed by updating the Reversals functionality to be more in-line with the intended definition of a reversal as part of VD-23140.	Verify that: The Reversal Status column value is displayed correctly. The Reversal Action column is editable when an action has to be performed by the Analyst on the Reversal line.
VD-25649	Date Numeric	The date field value format was not consistent across all New Submission and Ineligible Service Provider Workflow pages.	The date field value format was not consistent across all Submission and Ineligible Service Provider Workflow pages. This issue occurred due to a coding gap as a consistent date format was not used to populate the date field value throughout the application. This issue has been fixed by setting the global variables to handle API formatting and display formatting to populate all the date field values in MMDDYYYY format.	Verify that the date field value is displayed in MMDDYYYY format across all New Submission and Ineligible Service Provider Workflow pages.
VD-25278	Ineligible Service Provider	An exception occurred when importing the Ineligible Service Provider rows	When importing Ineligible Service Provider rows to the Ineligible Service Provider content area, an error occurred when the imported rows' ISP effective dates did not fall in the range of the dataQ dates stored in the Pharmacy Master table. This issue has been fixed by removing the data logic of comparing the ISP effective dates to the dataQ dates when importing the Ineligible Service Provider rows to the Ineligible Service Provider content area.	Verify that importing the Ineligible Service Provider rows to the Ineligible Service Provider content area completes successfully even though the ISP effective dates did not fall in the range of the dataQ dates stored in the Pharmacy Master table.
VD-27161	Monitor & Ineligible Service Provider	The ISP-related process names were not displayed on the Monitor page.	When importing the Ineligible Service Providers list to the Ineligible Service Provider content area, on the Monitor List page the ISP-related process names of ISP Import, ISP Validate, and ISP Publish, were not listed. This issue occurred due to a coding gap as the ISP-related processes were not included in the monitor query. This issue has been fixed by Updating the monitor query to display all associated ISP-related process names within the Monitor List table.	On the Monitor page, in the Monitor list table, the Ineligible Service Provider process names ISP Import, ISP Validate, and ISP Publish are listed and valid information is displayed.
VD-24306	Roles and Privileges	An empty value was populated in the IVD_TOPR table UUID and USERNAME columns when multiple users were imported through the UAM portal.	NULL value was populated for the UUID and USERNAME columns in the IVD_TOPR table when the number of imported users through the UAM portal exceeded 100. This issue occurred due to a coding gap, as the UAM Rest call was not able to sync the data in the database table when the number of imported users exceeded 100. This issue has been fixed by updating the UAM REST call. Also, batching logic has been added to retrieve the users in batches and sync them in the Validata IVD_TOPR table when importing a larger quantity of users.	Import more than 100 users through the UAM portal. Verify that the sync of users between the UAM and Validata database is completed successfully and the values for the UUID and USERNAME columns in the IVD_TOPR table are retrieved correctly.
VD-26032	Role and privileges	Allow users to view and access the left menu panel based on the access control.	On the new UX, in the left navigation panel, the user was able to access the menu items although it was not listed under their permission. This issue occurred as the left navigation panel menu items access permission was not controlled by the UAM resource. This issue has been fixed by providing access to the left navigation panel menu items based on the permission the user is assigned. This access permission is controlled by the UAM resource.	Verify that the user can access only the menu items to which they are given access permission by the UAM resource.
VD-25305	License	When a customer did not procure either the Coverage Gap or the 340B Vigilance add-on licenses, the user interface components pertaining to these sub-modules should not be listed on the application page.	The New Submission creation Submission Type page and 340B evaluation-related user inputs were displayed on the user interface, even though the customer did not procure Coverage Gap or 340B Vigilance add-on licenses. This issue occurred due to a coding gap where the permission assigned to the user was not considered when displaying the UX pages/components to the logged-in user. This issue has been fixed by exposing the user interface elements based on the license procured.	When a customer does not have a Coverage Gap add-on license, verify that, when creating a new Submission the Submission Type page is not displayed. The user should directly navigate to the File Selection tab page. When a customer does not have a 340B Vigilance license, verify that the 340B evaluation-related user inputs are not displayed on the user interface.
VD-20329	Coverage Gap Submission	An error occurred when filtering the Error Code column on the Reversals list table	On the Coverage Gap Submission Reversals list table, when filtering rows by applying a filter on the Error Code column, an error was displayed and the table rows were not filtered. This issue occurred due to a coding gap as applying a filter on the Error Code column was not available. This issue has been fixed by supporting the apply filter on the Error Code column.	On the Coverage Gap Submission Reversals list table, verify that the filtering Error Code column is working.
VD-21437	Coverage Gap Submission	The default values for the Validation period start date and end date were not populated when the user provided only one date value and left the other blank.	In the new Coverage Gap Submission in the Validation automation section or the Coverage Gap Submission Validation Options drawer, in the Validation period start date/end date user input, when the user provided only the start date and ‘tabs out’ of the field and leaving the end date as blank, then the default value for the end date value was not populated. Similarly, when only the end date value was provided and the start date was left blank, the default value for the start date value was not populated. This issue occurred due to a coding gap as the default values for the Validation period start date/end date user input were not populated when the user provided only one value and left the other blank. This issue has been fixed by updating the code to populate the default value as follows: When the Validation period start date is specified but the Validation period end date is not provided then the end date should be considered as 12/31/9999. When the Validation Period start date is not specified but the Validation period end date is provided then the start date should be considered 01/01/1900.	In the new Coverage Gap Submission in the Validation automation section or the Coverage Gap Submission Validation Options drawer, in the Validation period start date/end date user input, specify only the start date or end date value verify the other value is defaulted as below: When the Validation period start date is specified but the Validation period end date is not provided then the end date is considered as 12/31/9999. When the Validation Period start date is not specified but the Validation period end date is provided then the start date is considered as 01/01/1900.
VD-21837	Coverage Gap Submission	In the Coverage Gap Submission overflow menu the 'Validate & options' was enabled and selectable even though there was an error in the workflow file upload step.	When creating a Coverage Gap Submission, when there was an error in the workflow file upload step, in the overflow menu the 'Validate & options' was enabled and selectable by users. As the file upload was not completed and there were no data lines to be validated the 'Validate & options' should be in read-only (not selectable). This issue occurred due to a coding gap as the Total data lines and Submission Status were not considered to set the enable/disable state of the Validate & options button. This issue has been fixed by updating the code to make the 'Validate & options' enabled and selectable by users only when the Submission status value is not In Progress, Error, or Completed.	Verify that: The 'Validate & options' is disabled if no data lines are present in the Data Lines tab to run validation against. When the Coverage Gap data file is imported successfully but there is an error in the file tab due to a different file upload, the ‘Validate & options’ button is enabled.
VD-24047 VD-24048	Coverage Gap Submission	Coverage Gap Submission header and data line-level comment were not retained after migration from a version prior to Fall 2023 to Fall 2023 release.	When the Coverage Gap Submissions were migrated from a version prior to Fall 2023 to the Fall 2023 release, the comments provided at the Submission header and data line in the previous version were not retained. This issue occurred due to a coding gap as the comments provided on the Coverage Gap Submission were maintained in the TECMF_NOTES table and the migration script implemented to migrate the comments to IVD_COMMENTS did not include the Coverage Gap Submission. This issue has been fixed by implementing a new script to migrate the comments for the Coverage Gap Submission header and data line-level.	Verify that when the Coverage Gap Submissions are migrated from a version prior to Fall 2023 to Fall 2023 release, the comments provided at the submission header and data line level are retained and displayed on the user interface.
VD-24027	Coverage Gap Submission	Incorrect Status and Workflow displayed when the Coverage Gap Submissions were migrated from a version prior to Fall 2023 to the Fall 2023 release.	Incorrect Submission Status and Workflow status displayed for the migrated Coverage Gap Submissions. In the pre-migrated application, the CG data transaction file was in Ready-to-Import status. After migration, the Submission Status should have been New, and Workflow: File Status should have been Error, but instead of that Submission Status was displayed as Error and Workflow: File Status displayed as Completed. In the pre-migrated application, the CG data transaction file import was in Error status, after migration the submission Workflow should have been displayed as below: Workflow: File Status as Error Workflow: Validation as Not started Workflow: Dispute status as Not started Instead, the Submission Workflow status was displayed as Completed for File, Validation, and Dispute. This issue occurred as the migration script was not handling the Submission status correctly when in the pre-migrated version the file was in Ready-to-Import or error status. This issue has been fixed by updating the migration script to not update the Submission as completed that had an error in the pre-migrated version. Note: Ensure that all transaction files are imported before running the migration script to migrate the Transaction Files to the Fall 2023 release. In the pre-migrated version, if the Submission status value was Error (resulted due to file import error), after migration the files will not get imported as the migration script cannot import the file. Hence the user is required to delete the files manually. Deleted transaction files will be restored in the file share and can be included in a newly created Submission.	Verify that the Status and Workflow status are displayed correctly for the migrated Coverage Gap Submissions.
VD-24800	Coverage Gap Submission	The Dispute Status of the lines was updated in the Data Lines list table incorrectly.	On the Coverage Gap Submission Data Lines list table, the user applied a filter to list the data lines with a specific Dispute Status value and checked the Select All check box for selecting all the filtered rows on the table. When the user disputed the selected rows by adding the Dispute Information, the Dispute Status of all the rows except the rows with Dispute Status value as Upheld got updated to ‘Ready to re-submit’ instead of updating only the selected filtered rows. This issue occurred due to incorrect handling of the Select All action. When the Select All condition was true, no item IDs were sent to the API, and the API call was incorrectly updating all the rows from the table whose Dispute Status value is not Upheld. This issue has been fixed by updating the API to request to send the items IDs of the lines that were part of the applied filtered and updating only those specific row’s statuses when a dispute action is performed.	On the Coverage Gap Submission Data Lines list table apply a filter to view the rows with specific Dispute Status. Check the Select All check box for selecting all the filtered rows on the table. Perform dispute action. Verify that the Dispute Status is updated only for the filtered lines on the Data Lines list table.
VD-23697	Coverage Gap Submission	An incorrect value was displayed in the Coverage Gap Submission data line history log.	This fix addresses the following issues related to the Coverage Gap Submission data line history log: When Export is done for the same data line more than once, all the instances were logged as Submitted in the history. For the first export action, only history should be logged as Submitted and for the subsequent export actions, it should be logged as Resubmitted. For the Override-Excluded and Override-Included actions in the history drawer, for the Status column, the prefix Override was missed and the value was displayed as Included/Excluded. For the Read TPA Dispute File action, in the history drawer, for the Status column, an incorrect status was displayed. The override prefix was not included when the history was logged for overriding the include and exclude Line Status. In the history drawer, for the Details column, the Primary Dispute Reason code and Dispute Information were not shown. These issues occurred because: The Resubmitted action was not included in the IVDA_ITEM_HISTORY view and the views.sql file was not capturing the correct status for the Resubmit action. In the views.sql file, the log information was not captured correctly when the history was logged for overriding the include and exclude of the data line Line Status. The logic was not handled correctly for reading the TPA Dispute File action. The change details were not captured in the views.sql file that was referenced to populate the Details column value. These issues have been fixed by: Adding resubmitted action in procedure and views.sql file to capture the history log for resubmit action. Including override prefix to Include/Exclude action in the Status column, when the history is logged for overriding the include and exclude of the data line Line Status. Including override prefix to Include/Exclude action in the Status column, when the history is logged for Read TPA Dispute File action. Including Primary Dispute Reason code and Dispute Information to the Details column text.	For Coverage Gap Submission data lines, verify that in the history drawer for the Status, Action, and Details columns, the information is displayed correctly.
VD-23689	Coverage Gap Submission	Incorrect information displayed in the Coverage Gap Submission history drawer	This fix addresses the following issues on the Coverage Gap Submission history drawer: When an Export Dispute action is done for the first time on a Coverage Gap submission, in the submission history the log for the respective action was retrieved as “EXPORT DISPUTE-RESUBMITTED” instead of the “EXPORT DISPUTE-SUBMITTED” in the Action column. In the Target Object column Submission was displayed instead of File and in the Target Name column, the Name of the Submission was displayed instead of <Name of the Data file>. These issues occurred as: An incorrect action was captured when the user performed the export of the dispute report first time. An incorrect value was fetched for the Target Name and Target Column from the Submission history table. This issue has been fixed by populating the correct data in the Action, Target Name, and Target Object columns within the Coverage Gap Submission history drawer.	Verify that: When an Export Dispute action is done for the first time on a Coverage Gap submission, in the submission history the log for the respective action was retrieved as “EXPORT DISPUTE-SUBMITTED” in the Action column. In the Target Object and Target Name column File and the <Name of the Data file> are displayed respectively.
VD-24799	Coverage Gap Submission	Dispute Reason Code was removed on overriding errors for data lines and did not stamp back on the data lines when the error override action reverted via the Undo action.	When the user has overridden the error severity for the Coverage Gap Submission data lines, the Dispute Reason Codes assigned on the lines were removed. But when the user reverted the previously performed overrides and the lines were assigned back with the originally stamped error severity level, the previously stamped Dispute Reason Code value was not assigned back to the line. This issue occurred due to a coding gap and reverting the error severity override did not return the Dispute Reason Code value originally stamped on the data lines. This issue has been fixed by updating the script to restore the reason codes when the error severity was overridden.	Revert the error severity overrides for the CG Submission data lines, and verify that the originally stamped Dispute Reason Code values are retained back on the data lines.
VD-23786	Coverage Gap Submission	An exception occurred when performing bulk override followed by undo override for the same set of lines in one save.	For Coverage Gap Submissions, on the Data lines tab, when the user performed bulk override of data lines followed by undo override (reverting to the original severity level) for the same set of data lines in one instance an error was displayed. This issue occurred due to a coding gap because both the errorOverride and undoErrorOverride were being called in parallel which was an async call instead of an await call to execute the function one after the other. This issue has been fixed by changing the API and UI request when bulk override is performed along with undo in the same Save action.	Perform bulk override of data lines followed by undo override (reverting to the original severity level) for the same set of data lines in the same save action. Verify that the undo action is completed successfully.
VD-23695	Coverage Gap Submission	An additional log was generated in the history when the Dispute toggle was set to 'No'.	On the Coverage Gap Submission Data line list table when the Dispute toggle was set to ‘No’, an additional log was entered in the history grid that indicated that the Dispute Information column is also updated. But as per the action for setting the Dispute toggle to ‘No’, the history should be logged only for the Dispute Status field update. This issue occurred due to a coding gap as setting the Dispute toggle to ‘No’ action resulted in a new history line for deleting dispute information. This issue has been fixed by removing the history line for deleting dispute information action.	Verify that when the Dispute toggle is set to ‘No’, only one history line is registered in the history grid.
VD-24474	Database Import	The database installation failed	When performing the database installation, it failed due to missing functions/procedures in the syntax. This issue has been fixed by adding missing functions/procedures in the full install script.	Verify that the database installation is completed successfully.
VD-25336	Migration	When migrating the users from a prior release to Fall 2023, the user account status was not retained after migration.	When the user accounts were migrated from a release prior to Fall 2023 to the Fall 2023 release, the user account status was not retained after migration. A few user accounts with inactive status in the previous release were assigned with active status after migration. This occurred due to a configuration issue, as there was no mechanism in UAM to identify the inactive accounts when doing the syncing process. This issue has been fixed by introducing a flag 'isEnabled' in UAM, which contains one of the following values: True: Specifies the user account is active. False: Specifies the user account is inactive.	Verify that the user account status was retained after migration.
VD-25670 Note: The original fix addressed a portion of the scenario and the rest were addressed in Fall 2023 RP2 HF1 release, which is why the same ticket is seen in that Release Notes doc.	~~Browse File Share~~	~~Issues with Browse file share option~~	~~This fix addresses the following issues within the Browse file share option:~~ ~~The Browse File Share option was not available for the users who do not have access to the ‘Transaction File Share' page.~~ ~~The Transaction file share menu was accessible for the users who did not have the privilege to access the menu. However, when the user clicked the menu, a blank page with an error was displayed.~~ ~~Utilization files that were previously included in a Submission and processed were listed on the Browse file share drawer grid.~~ ~~These issues occurred because:~~ ~~Permissions were not implemented for the Browse File Share option on the new Submission workflow.~~ ~~The transaction file share menu was not hidden for users who did not have permission to access the menu.~~ ~~The processed files were not restricted to be listed on the Browse file share drawer grid.~~ ~~To fix these issues, the following changes have been made:~~ ~~The Browse File Share is available for all Flex users.~~ ~~When a user does not have the appropriate privilege, the Transaction file share menu is hidden on the left menu panel.~~ ~~Only unprocessed utilization files are listed on the Browse file share drawer grid.~~	~~Verify that:~~ ~~The Browse File Share is accessible to all users.~~ ~~When a user does not have the appropriate privilege, the Transaction file share menu is not visible on the user interface.~~ ~~Only unprocessed utilization files are listed on the Browse file share drawer grid for user selection.~~
VD-22875	Notifications	An issue with the Notification search box.	When the user clicked the Notification icon (available in the top right corner) and using the search text tried to filter the available notifications, by specifying the text in the search textbook, the search result was listed on every text entry and a few times the result list was not refreshed when the user entered more text to refine search. This issue occurred due to a coding gap as the asynchronous timing for loading notifications was not handled in the application. When a bunch of consecutive requests were sent the last request was not loaded ignoring the previous results. This issue has been fixed by: Listing the search result when the user specifies a minimum of three characters in the search text box. Search waits when the user pauses entering text in the search text.	Verify that the search result is displaying based on the user input specified in the search text box.

Issue ID

Component

Issue Title

Description

Test Impact

VD-25627

Submissions

In the New Submission creation wizard, Header details tab, Validation automation section, in the Validation Set drop-down list, the validation sets options were listed randomly without any sorting order.

This issue occurred due to a coding gap as the listing of the Validation options in the Validation Set drop-down list in the new UX was not in sync with the older UX.

This issue has been fixed by listing the Validation Sets in alphabetical order based on the name, followed by the version to enhance the usability of the Validation Set drop-down list.

Within the Submission header section, open the Validation Options drawer. Verify that the validations set are listed in ascending order based on the name, followed by the version in the Validation Set drop-down.
In the New Submission creation wizard, Header details tab, Validation automation section, in the Validation Set drop-down list, verify that the validations set are listed in ascending order based on the name, followed by the version.

VD-25626

Submissions

In the Mapping Set drop-down list, the Mapping Set names were listed randomly without any sorting order.

When creating a New Submission, in the File Selection page, in the Included Files table, in the Mapping Set column drop-down list the Mapping Set names were listed randomly without any sorting order.

This issue occurred due to a coding gap as the listing of the options in the Mapping Set drop-down in the new UX was not in sync with the older UX.

This issue has been fixed by listing the Mapping Sets in alphabetical order based on the name followed by the version to enhance the usability of the Mapping Set drop-down list.

Verify that the mapping sets are listed in ascending order based on the name, followed by the version in the Mapping Set column drop-down list.

VD-25289
VD-21811

Submissions

A blank value was displayed for the Status field when the user clicked the tooltip icon in the Filters Applied field.

In the Submission workflow pages (Submissions list, Line Level Details list, Data Lines list etc..) on the list tables when the user applied a filter for viewing the rows with a filtered status value, in the Filters Applied on clicking the tooltip icon, a blank value was displayed for the Status field in the listed details.

This issue occurred due to a coding gap as the property was not included in the Filter-Saved Searches popover component to display the Status value.

This issue has been fixed by adding the missing property to display the Status value in the Filter Saved Searches popover component.

Apply multiple filters on the list tables in the Submission workflow pages (Submissions list, Line Level Details list, Data Lines list etc..). Verify that on clicking the tooltip icon in the Filters Applied field, the popover component is displaying all details related to the applied filters.

VD-24305

Submissions

The Line Status was displayed incorrectly when the Submissions were migrated from a version prior to Fall 2023 to the Fall 2023 release.

When the Submissions were migrated from a version prior to Fall 2023 to the Fall 2023 release, the value for the Line Status column was not displayed correctly for the utilization lines, when the line's error code severity level was manually overridden before migrating. Instead of displaying the Line Status value as Override Included or Override Excluded, it was displayed as Included/Excluded.

This issue occurred due to a coding gap when the line was manually overridden in the transaction items table after the last validation run, the Line Status was not retrieved correctly post-migration.

This issue has been fixed by creating a migration script to fill in the manual override flag field to capture if any overrides occurred in the transaction tables after the last validation, for both Coverage Gap and Non-Coverage Gap Submissions.

Verify that when the line's error code severity level was manually overridden before, post-migration the Line Status column value is displayed correctly as Override Included or Override Excluded.

VD-25399

Submissions

An exception occurred when the user performed a sort on the Comments column on the Submissions list table.

On the Submissions list table, when the user clicked the Comments column to sort the column data, an error message was displayed on the user interface and the user was unable to proceed with this action.

This issue occurred due to a coding gap as the API call to sort the Comment column was not established.

This issue has been fixed by updating the API request to allow sorting and filtering for the Comment column.

Verify that, on the Submissions list table, when the user clicks on the Comment column header, sorting is applied to the rows and no error message appears.

VD-25744

Submission List

An incorrect value is displayed in the % Excluded column in the Submissions list grid.

When the Submission was created and validated, although the validation result excluded a small quantity of utilization lines, on the Submission list grid in the % Excluded column a Zero (0.00%) value was displayed. The correct percentage of the excluded lines was not populated.

This issue occurred due to a coding gap when a Submission contains a large number of lines and only a few lines were excluded. In those Submissions, the excluded % value is a long fraction. When populating the percentage value, the application shows the value in 2 digits after decimal points. For long fraction values, when displaying 2 digits after decimal points, it was shown as 0.00%.

This issue has been fixed by increasing the accuracy to display decimal points as 0.01% and inserting a value formatter to show a less than symbol before the % value, for example <0.01%.

Verify that when utilizations are excluded, on the Submission list grid in the % Excluded column the excluded percentage value is populated correctly. When the percentage of exclusion is a long fraction, verify that a less than symbol is prefixed to the value, which indicates the percentage excluded is less than the decimal point presented.

VD-20914

Submission Details

The username value was populated rather than the user’s first name and last name for a few user interface components

On the Submission workflow, for a few user interface fields like Last Updated, Created by, Deleted by etc.. the username value was displayed instead of the user’s first name and last name.

This issue occurred as the username was stored in the audit column that was referenced to retrieve the first name and last name of the user to populate in the Last Updated, Created by, Deleted by, etc. fields on the user interface.

This issue has been fixed by populating the user's first name and last name instead of the username value in the Last Updated, Created by, Deleted by etc. fields. In the absence of the first and last name of the user, the user name is populated.

Verify that the correct user name value is populated on the various Submission workflow pages.

VD-25463

Validations

Reimbursement Amount and Invalid Check Digit Validations were missed in Fall 2023.

The Reimbursement Amount validation and Invalid Check Digit validation introduced in the Spring 2023 release were missed in the Fall 2023 code line.

This issue occurred due to a coding gap as the Reimbursement Amount and Invalid Check Digit validation introduced in a previous release were not ported to the Fall 2023 code line.

This issue has been fixed by including the missed Reimbursement Amount validation and Invalid Check Digit validation to the Fall 2023 code line.

Verify that:

The Reimbursement Amount validation is accessible and executes accurately without any errors.
The Invalid Check Digit validation is accessible and executes accurately without any errors.

VD-21430

Delete Submission

Update the delete submission popover name

When deleting a selected Submission, the delete confirmation popover displayed the header text as “Delete submissions”. To improve the user interface usability purpose, the header text has been changed to display “Confirm delete”.

On the Submission list table, click the delete option to delete a select Submission. Verify that on the popover the header text is displayed as “Confirm delete”.

VD-26511

Non-Coverage Gap Submission

Contract ID values in the Publish drawer input filter section are missing when a Submission contains more than one utilization file associated with more than one Contract ID.

When a Submission contains more than one utilization file and more than one Contract ID is aligned with the aggregate volume of utilization lines, and when in the Publish drawer, not all Contract IDs are listed in the Contract filter section, hence the user was unable to publish the Submission by including a Contract ID.

This issue occurred due to a coding gap where the distinct contracts from the utilization files/lines included in the Submission were not retrieved in the Contracts filter section.

This issue has been fixed by tuning the query to fetch the distinct Contracts from the utilization lines included in the Submission and list them in the Contracts filter section.

Verify that Contract IDs are listed in the Contract filter section when a Submission has more than one utilization file and you can select a Contract ID to publish the Submission.

VD-25401

Non-Coverage Gap Submission Line Level Details

View Error Overrides and Override Line Status options were enabled for the users even though the access rules were not defined for the user.

An exception occurred when the user clicked the View Error Overrides and Override Line Status on the Non-Coverage Gap Submission, Line Level Details tab page.

This issue occurred because the View Error Overrides and Override Line Status buttons were enabled for user who does not have permission to perform these actions.

This issue has been fixed by disabling the action buttons on the user interface to which the respective logged-in user does not have the authorization to perform.

Verify that when the logged-in user does not have access to perform View Error Overrides and Override Line Status and respective buttons are disabled on the user interface.

VD-25745

Non-Coverage Gap Submission Line Level Details

Technical syntax was displayed on the Manage Details drawer

When the Manage Details drawer was opened from the Non-Coverage Gap or Coverage Gap Submission header section, a Technical syntax was displayed instead of the user-readable text header for the Contract details section.

This issue occurred due to a coding gap. The technical syntax was populated instead of the user-readable text header name when it took a longer time to retrieve the header name due to slow internet bandwidth.

This issue has been fixed by removing the duplicate technical syntax for the Contract details header and introducing a method to wait for the Manage Details drawer to load before showing translated technical syntax.

Verify that in the Manage Details drawer, the correct user-readable text is displayed for the header labels.

VD-22364

Non-Coverage Gap Submission Line-Level Details

An exception occurred when downloading the Non-Coverage Gap Submission Line Level Details list table rows

When downloading the Non-Coverage Gap Submission Line Level Details list table rows, an exception was thrown when the number of rows on the table was large.

This performance issue occurred when the number of rows on the Line Level Details list table was large and when performing row download action, it reached the upper cap of memory and CPU on processing.

This performance issue has been fixed by performing query tuning and optimizing memory during the download process.

Note: On the Line-Level Details list table when there is a large number of rows and attempting to download as an XLS format, an exception may still display and is being addressed in an upcoming Hotfix (HF).

On the Line Level Details list table when there is a large number of rows, verify that the downloading rows is completed successfully in CSV File Format.

VD-25522

Non-Coverage Gap Line-Level Details

An exception occurred when doing an undo action for a Line-Level Error Severity Override.

In the Non-Coverage Gap Submission, in the Line Level Details list table, when doing an undo action for a Line-Level Error Severity Override, an error was displayed.

This issue occurred because, in the UAM YAML (programming language) Utility, the UNDOOVERRIDE was missing in the transactionRecord and transactionRecordCGData resource.

This issue has been updated by adding UNDOOVERRIDE scope in the transactionRecord and transactionRecordCGData resource in the AM YAML Utility.

For a Non-Coverage Gap Submission, in the Line-Level Details list table, override the error severity level for a line then undo the override. Verify that the undo action is completed successfully.

VD-24471

Non-Coverage Gap Submission

When performing a data grid download from the Exports grid, the Options column and its details were not included in the file.

On the Non-Coverage Gap Submission, Exports grid, when the user downloaded rows to an Excel or CSV file, the Options column along with its relevant details was not included in the downloaded file.

This issue occurred due to a coding gap as the Options column was not included in the view and also in the graphQL query.

This issue has been fixed by adding the Options column to the view and graphQL query.

Verify that the Options column along with the relevant details is available in the downloaded file.

VD-21397

Non-Coverage Gap Submission Publish

Definitions of the acronyms for the Publish Options were not populated in the Publish drawer.

In the Non-Coverage Gap Submission, Publish drawer, in the Publish options user input, the definitions of the acronyms were not displayed.

In the Publish options user input, previously only the Publish option acronyms, such as CP, CPP, etc., were listed. Now, with this fix the definition has been added next to acronyms which specifies what the publish option means. For example, CP stands for Contract/Product, and CPP stands for Contract/Plan/Product.

In the Publish drawer, Publish options drop-down list, verify that the acronyms along with the definition text are listed.

VD-22926

Non-Coverage Gap Submission Reversal

On the Reversals list table, the Reversal Status and Reversal Action columns were not reset when the line's Publish Status was changed to Published

On the Reversal list table, when the reversal line's Publish Status was changed to Published, the value for Reversal Status was not changed to New, and the Reversal Action drop-down was read-only state

This issue occurred due to a coding gap where the Reversal Status and Reversal Action columns were not refreshed when the Publish Status column was updated.

This issue has been fixed by updating the Reversals functionality to be more in-line with the intended definition of a reversal as part of VD-23140.

Verify that:

The Reversal Status column value is displayed correctly.
The Reversal Action column is editable when an action has to be performed by the Analyst on the Reversal line.

VD-25649

Date Numeric

The date field value format was not consistent across all New Submission and Ineligible Service Provider Workflow pages.

The date field value format was not consistent across all Submission and Ineligible Service Provider Workflow pages.

This issue occurred due to a coding gap as a consistent date format was not used to populate the date field value throughout the application.

This issue has been fixed by setting the global variables to handle API formatting and display formatting to populate all the date field values in MMDDYYYY format.

Verify that the date field value is displayed in MMDDYYYY format across all New Submission and Ineligible Service Provider Workflow pages.

VD-25278

Ineligible Service Provider

An exception occurred when importing the Ineligible Service Provider rows

When importing Ineligible Service Provider rows to the Ineligible Service Provider content area, an error occurred when the imported rows' ISP effective dates did not fall in the range of the dataQ dates stored in the Pharmacy Master table.

This issue has been fixed by removing the data logic of comparing the ISP effective dates to the dataQ dates when importing the Ineligible Service Provider rows to the Ineligible Service Provider content area.

Verify that importing the Ineligible Service Provider rows to the Ineligible Service Provider content area completes successfully even though the ISP effective dates did not fall in the range of the dataQ dates stored in the Pharmacy Master table.

VD-27161

Monitor &

Ineligible Service Provider

The ISP-related process names were not displayed on the Monitor page.

When importing the Ineligible Service Providers list to the Ineligible Service Provider content area, on the Monitor List page the ISP-related process names of ISP Import, ISP Validate, and ISP Publish, were not listed.

This issue occurred due to a coding gap as the ISP-related processes were not included in the monitor query.

This issue has been fixed by Updating the monitor query to display all associated ISP-related process names within the Monitor List table.

On the Monitor page, in the Monitor list table, the Ineligible Service Provider process names ISP Import, ISP Validate, and ISP Publish are listed and valid information is displayed.

VD-24306

Roles and Privileges

An empty value was populated in the IVD_TOPR table UUID and USERNAME columns when multiple users were imported through the UAM portal.

NULL value was populated for the UUID and USERNAME columns in the IVD_TOPR table when the number of imported users through the UAM portal exceeded 100.

This issue occurred due to a coding gap, as the UAM Rest call was not able to sync the data in the database table when the number of imported users exceeded 100.

This issue has been fixed by updating the UAM REST call. Also, batching logic has been added to retrieve the users in batches and sync them in the Validata IVD_TOPR table when importing a larger quantity of users.

Import more than 100 users through the UAM portal. Verify that the sync of users between the UAM and Validata database is completed successfully and the values for the UUID and USERNAME columns in the IVD_TOPR table are retrieved correctly.

VD-26032

Role and privileges

Allow users to view and access the left menu panel based on the access control.

On the new UX, in the left navigation panel, the user was able to access the menu items although it was not listed under their permission.

This issue occurred as the left navigation panel menu items access permission was not controlled by the UAM resource.

This issue has been fixed by providing access to the left navigation panel menu items based on the permission the user is assigned. This access permission is controlled by the UAM resource.

Verify that the user can access only the menu items to which they are given access permission by the UAM resource.

VD-25305

License

When a customer did not procure either the Coverage Gap or the 340B Vigilance add-on licenses, the user interface components pertaining to these sub-modules should not be listed on the application page.

The New Submission creation Submission Type page and 340B evaluation-related user inputs were displayed on the user interface, even though the customer did not procure Coverage Gap or 340B Vigilance add-on licenses.

This issue occurred due to a coding gap where the permission assigned to the user was not considered when displaying the UX pages/components to the logged-in user.

This issue has been fixed by exposing the user interface elements based on the license procured.

When a customer does not have a Coverage Gap add-on license, verify that, when creating a new Submission the Submission Type page is not displayed. The user should directly navigate to the File Selection tab page.

When a customer does not have a 340B Vigilance license, verify that the 340B evaluation-related user inputs are not displayed on the user interface.

VD-20329

Coverage Gap Submission

An error occurred when filtering the Error Code column on the Reversals list table

On the Coverage Gap Submission Reversals list table, when filtering rows by applying a filter on the Error Code column, an error was displayed and the table rows were not filtered.

This issue occurred due to a coding gap as applying a filter on the Error Code column was not available.

This issue has been fixed by supporting the apply filter on the Error Code column.

On the Coverage Gap Submission Reversals list table, verify that the filtering Error Code column is working.

VD-21437

Coverage Gap Submission

The default values for the Validation period start date and end date were not populated when the user provided only one date value and left the other blank.

In the new Coverage Gap Submission in the Validation automation section or the Coverage Gap Submission Validation Options drawer, in the Validation period start date/end date user input, when the user provided only the start date and ‘tabs out’ of the field and leaving the end date as blank, then the default value for the end date value was not populated. Similarly, when only the end date value was provided and the start date was left blank, the default value for the start date value was not populated.

This issue occurred due to a coding gap as the default values for the Validation period start date/end date user input were not populated when the user provided only one value and left the other blank.

This issue has been fixed by updating the code to populate the default value as follows:

When the Validation period start date is specified but the Validation period end date is not provided then the end date should be considered as 12/31/9999.
When the Validation Period start date is not specified but the Validation period end date is provided then the start date should be considered 01/01/1900.

When the Validation period start date is specified but the Validation period end date is not provided then the end date is considered as 12/31/9999.
When the Validation Period start date is not specified but the Validation period end date is provided then the start date is considered as 01/01/1900.

VD-21837

Coverage Gap Submission

In the Coverage Gap Submission overflow menu the 'Validate & options' was enabled and selectable even though there was an error in the workflow file upload step.

When creating a Coverage Gap Submission, when there was an error in the workflow file upload step, in the overflow menu the 'Validate & options' was enabled and selectable by users. As the file upload was not completed and there were no data lines to be validated the 'Validate & options' should be in read-only (not selectable).

This issue occurred due to a coding gap as the Total data lines and Submission Status were not considered to set the enable/disable state of the Validate & options button.

This issue has been fixed by updating the code to make the 'Validate & options' enabled and selectable by users only when the Submission status value is not In Progress, Error, or Completed.

Verify that:

The 'Validate & options' is disabled if no data lines are present in the Data Lines tab to run validation against.
When the Coverage Gap data file is imported successfully but there is an error in the file tab due to a different file upload, the ‘Validate & options’ button is enabled.

VD-24047

VD-24048

Coverage Gap Submission

Coverage Gap Submission header and data line-level comment were not retained after migration from a version prior to Fall 2023 to Fall 2023 release.

When the Coverage Gap Submissions were migrated from a version prior to Fall 2023 to the Fall 2023 release, the comments provided at the Submission header and data line in the previous version were not retained.

This issue occurred due to a coding gap as the comments provided on the Coverage Gap Submission were maintained in the TECMF_NOTES table and the migration script implemented to migrate the comments to IVD_COMMENTS did not include the Coverage Gap Submission.

This issue has been fixed by implementing a new script to migrate the comments for the Coverage Gap Submission header and data line-level.

Verify that when the Coverage Gap Submissions are migrated from a version prior to Fall 2023 to Fall 2023 release, the comments provided at the submission header and data line level are retained and displayed on the user interface.

VD-24027

Coverage Gap Submission

Incorrect Status and Workflow displayed when the Coverage Gap Submissions were migrated from a version prior to Fall 2023 to the Fall 2023 release.

Incorrect Submission Status and Workflow status displayed for the migrated Coverage Gap Submissions.

In the pre-migrated application, the CG data transaction file was in Ready-to-Import status. After migration, the Submission Status should have been New, and Workflow: File Status should have been Error, but instead of that Submission Status was displayed as Error and Workflow: File Status displayed as Completed.

In the pre-migrated application, the CG data transaction file import was in Error status, after migration the submission Workflow should have been displayed as below:

Workflow: File Status as Error

Workflow: Validation as Not started

Workflow: Dispute status as Not started

Instead, the Submission Workflow status was displayed as Completed for File, Validation, and Dispute.

This issue occurred as the migration script was not handling the Submission status correctly when in the pre-migrated version the file was in Ready-to-Import or error status.

This issue has been fixed by updating the migration script to not update the Submission as completed that had an error in the pre-migrated version.

Note: Ensure that all transaction files are imported before running the migration script to migrate the Transaction Files to the Fall 2023 release. In the pre-migrated version, if the Submission status value was Error (resulted due to file import error), after migration the files will not get imported as the migration script cannot import the file. Hence the user is required to delete the files manually. Deleted transaction files will be restored in the file share and can be included in a newly created Submission.

Verify that the Status and Workflow status are displayed correctly for the migrated Coverage Gap Submissions.

VD-24800

Coverage Gap Submission

The Dispute Status of the lines was updated in the Data Lines list table incorrectly.

On the Coverage Gap Submission Data Lines list table, the user applied a filter to list the data lines with a specific Dispute Status value and checked the Select All check box for selecting all the filtered rows on the table. When the user disputed the selected rows by adding the Dispute Information, the Dispute Status of all the rows except the rows with Dispute Status value as Upheld got updated to ‘Ready to re-submit’ instead of updating only the selected filtered rows.

This issue occurred due to incorrect handling of the Select All action. When the Select All condition was true, no item IDs were sent to the API, and the API call was incorrectly updating all the rows from the table whose Dispute Status value is not Upheld.

This issue has been fixed by updating the API to request to send the items IDs of the lines that were part of the applied filtered and updating only those specific row’s statuses when a dispute action is performed.

On the Coverage Gap Submission Data Lines list table apply a filter to view the rows with specific Dispute Status. Check the Select All check box for selecting all the filtered rows on the table. Perform dispute action. Verify that the Dispute Status is updated only for the filtered lines on the Data Lines list table.

VD-23697

Coverage Gap Submission

An incorrect value was displayed in the Coverage Gap Submission data line history log.

This fix addresses the following issues related to the Coverage Gap Submission data line history log:

When Export is done for the same data line more than once, all the instances were logged as Submitted in the history. For the first export action, only history should be logged as Submitted and for the subsequent export actions, it should be logged as Resubmitted.
For the Override-Excluded and Override-Included actions in the history drawer, for the Status column, the prefix Override was missed and the value was displayed as Included/Excluded.
For the Read TPA Dispute File action, in the history drawer, for the Status column, an incorrect status was displayed. The override prefix was not included when the history was logged for overriding the include and exclude Line Status.
In the history drawer, for the Details column, the Primary Dispute Reason code and Dispute Information were not shown.

These issues occurred because:

The Resubmitted action was not included in the IVDA_ITEM_HISTORY view and the views.sql file was not capturing the correct status for the Resubmit action.
In the views.sql file, the log information was not captured correctly when the history was logged for overriding the include and exclude of the data line Line Status.
The logic was not handled correctly for reading the TPA Dispute File action.
The change details were not captured in the views.sql file that was referenced to populate the Details column value.

These issues have been fixed by:

Adding resubmitted action in procedure and views.sql file to capture the history log for resubmit action.
Including override prefix to Include/Exclude action in the Status column, when the history is logged for overriding the include and exclude of the data line Line Status.
Including override prefix to Include/Exclude action in the Status column, when the history is logged for Read TPA Dispute File action.
Including Primary Dispute Reason code and Dispute Information to the Details column text.

For Coverage Gap Submission data lines, verify that in the history drawer for the Status, Action, and Details columns, the information is displayed correctly.

VD-23689

Coverage Gap Submission

Incorrect information displayed in the Coverage Gap Submission history drawer

This fix addresses the following issues on the Coverage Gap Submission history drawer:

When an Export Dispute action is done for the first time on a Coverage Gap submission, in the submission history the log for the respective action was retrieved as “EXPORT DISPUTE-RESUBMITTED” instead of the “EXPORT DISPUTE-SUBMITTED” in the Action column.
In the Target Object column Submission was displayed instead of File and in the Target Name column, the Name of the Submission was displayed instead of <Name of the Data file>.

These issues occurred as:

An incorrect action was captured when the user performed the export of the dispute report first time.
An incorrect value was fetched for the Target Name and Target Column from the Submission history table.

This issue has been fixed by populating the correct data in the Action, Target Name, and Target Object columns within the Coverage Gap Submission history drawer.

Verify that:

When an Export Dispute action is done for the first time on a Coverage Gap submission, in the submission history the log for the respective action was retrieved as “EXPORT DISPUTE-SUBMITTED” in the Action column.
In the Target Object and Target Name column File and the <Name of the Data file> are displayed respectively.

VD-24799

Coverage Gap Submission

Dispute Reason Code was removed on overriding errors for data lines and did not stamp back on the data lines when the error override action reverted via the Undo action.

When the user has overridden the error severity for the Coverage Gap Submission data lines, the Dispute Reason Codes assigned on the lines were removed. But when the user reverted the previously performed overrides and the lines were assigned back with the originally stamped error severity level, the previously stamped Dispute Reason Code value was not assigned back to the line.

This issue occurred due to a coding gap and reverting the error severity override did not return the Dispute Reason Code value originally stamped on the data lines.

This issue has been fixed by updating the script to restore the reason codes when the error severity was overridden.

Revert the error severity overrides for the CG Submission data lines, and verify that the originally stamped Dispute Reason Code values are retained back on the data lines.

VD-23786

Coverage Gap Submission

An exception occurred when performing bulk override followed by undo override for the same set of lines in one save.

For Coverage Gap Submissions, on the Data lines tab, when the user performed bulk override of data lines followed by undo override (reverting to the original severity level) for the same set of data lines in one instance an error was displayed.

This issue occurred due to a coding gap because both the errorOverride and undoErrorOverride were being called in parallel which was an async call instead of an await call to execute the function one after the other.

This issue has been fixed by changing the API and UI request when bulk override is performed along with undo in the same Save action.

Perform bulk override of data lines followed by undo override (reverting to the original severity level) for the same set of data lines in the same save action. Verify that the undo action is completed successfully.

VD-23695

Coverage Gap Submission

An additional log was generated in the history when the Dispute toggle was set to 'No'.

On the Coverage Gap Submission Data line list table when the Dispute toggle was set to ‘No’, an additional log was entered in the history grid that indicated that the Dispute Information column is also updated. But as per the action for setting the Dispute toggle to ‘No’, the history should be logged only for the Dispute Status field update.

This issue occurred due to a coding gap as setting the Dispute toggle to ‘No’ action resulted in a new history line for deleting dispute information.

This issue has been fixed by removing the history line for deleting dispute information action.

Verify that when the Dispute toggle is set to ‘No’, only one history line is registered in the history grid.

VD-24474

Database Import

The database installation failed

When performing the database installation, it failed due to missing functions/procedures in the syntax.

This issue has been fixed by adding missing functions/procedures in the full install script.

Verify that the database installation is completed successfully.

VD-25336

Migration

When migrating the users from a prior release to Fall 2023, the user account status was not retained after migration.

When the user accounts were migrated from a release prior to Fall 2023 to the Fall 2023 release, the user account status was not retained after migration. A few user accounts with inactive status in the previous release were assigned with active status after migration.

This occurred due to a configuration issue, as there was no mechanism in UAM to identify the inactive accounts when doing the syncing process.

This issue has been fixed by introducing a flag 'isEnabled' in UAM, which contains one of the following values:

True: Specifies the user account is active.
False: Specifies the user account is inactive.

Verify that the user account status was retained after migration.

VD-25670

Note: The original fix addressed a portion of the scenario and the rest were addressed in Fall 2023 RP2 HF1 release, which is why the same ticket is seen in that Release Notes doc.

~~Browse File Share~~

~~Issues with Browse file share option~~

~~This fix addresses the following issues within the Browse file share option:~~

~~The Browse File Share option was not available for the users who do not have access to the ‘Transaction File Share' page.~~
~~The Transaction file share menu was accessible for the users who did not have the privilege to access the menu. However, when the user clicked the menu, a blank page with an error was displayed.~~
~~Utilization files that were previously included in a Submission and processed were listed on the Browse file share drawer grid.~~

~~These issues occurred because:~~

~~Permissions were not implemented for the Browse File Share option on the new Submission workflow.~~
~~The transaction file share menu was not hidden for users who did not have permission to access the menu.~~
~~The processed files were not restricted to be listed on the Browse file share drawer grid.~~

~~To fix these issues, the following changes have been made:~~

~~The Browse File Share is available for all Flex users.~~
~~When a user does not have the appropriate privilege, the Transaction file share menu is hidden on the left menu panel.~~
~~Only unprocessed utilization files are listed on the Browse file share drawer grid.~~

~~Verify that:~~

~~The Browse File Share is accessible to all users.~~
~~When a user does not have the appropriate privilege, the Transaction file share menu is not visible on the user interface.~~
~~Only unprocessed utilization files are listed on the Browse file share drawer grid for user selection.~~

VD-22875

Notifications

An issue with the Notification search box.

When the user clicked the Notification icon (available in the top right corner) and using the search text tried to filter the available notifications, by specifying the text in the search textbook, the search result was listed on every text entry and a few times the result list was not refreshed when the user entered more text to refine search.

This issue occurred due to a coding gap as the asynchronous timing for loading notifications was not handled in the application. When a bunch of consecutive requests were sent the last request was not loaded ignoring the previous results.

This issue has been fixed by:

Listing the search result when the user specifies a minimum of three characters in the search text box.
Search waits when the user pauses entering text in the search text.

Verify that the search result is displaying based on the user input specified in the search text box.