Version 3.31, Released November 24, 2021 Previous Release Notes
Click HERE for more information on the new v3.31-Hotfix1 dedicated to LABS, available 12/7/2021.
New Features
Batch Default Payer
Billing Users can now specify a Default Payer when creating a new batch or importing an 835 file. The Default Payer is not required when adding a batch manually because the user matches the payment, and the Charge selected may result in a different Payer than the entered default. On the New Batch screen, the new Default Payer field allows the selection of a single Payer and is located between Batch ID and Remittance Date. When importing an 835, a Payer selection is already required, so a default Payer is not needed. The system falls back to this Payer to find a match when there is no active Charge with a matching Id837 value.
|
|
The Default Payer displays on the Batches home screen between the Batch ID and the Default Payer.
And Default Payer displays in the header of the View Batch screen and can also be used to filter results.
When adding a new row to a batch, the Payer field is auto-populated with the default Payer but can be changed if desired.
The Default Payer can be changed when working in the Edit Batch screen.
This updates the Default Payer in the Batches grid and on the View Batch screen, but it does NOT update the Payer on the individual Remittance rows.
Non-Specific Payer Payments
A Non-Specific Payer Payment (NSPP) or PLB Segment amount can now be added, imported, and managed using the Remittances > Batches feature. When imported, the NSPP is included in the Batch with a Not Ready status, whereas imported Payments matched to a Client and Charge have a Ready status. Note that a negative NSPP amount in the 835 is reflected in EchoVantage as a positive payment amount. Conversely, a positive amount in the 835 is reflected in EchoVantage as a negative amount. For example, the highlighted PLB Segment is from the imported 835 file.
The records created after this file is imported are below. The NSPP record is outlined in red.
Select the row of the non-specific Payer Payment to view the details in the Edit NSPP screen.
The Edit NSPP screen displays limited information. There are no filters available on the left-hand side, and because this payment is not matched to a charge, Service and Claim information is not displayed. The Payment Amount field is required but can be updated to any amount, positive or negative, but cannot be $0.00.
Select the blue ADD NSPP button on the View Batch screen to manually add an NSPP to an existing or user created batch.
The New NSPP screen opens and has the same fields and entry requirements as the Edit NSPP screen.
The NSPP can be marked as Ready/Not Ready or Deleted from the New NSPP or Edit NSPP screens or by using the bulk actions on the View Batch screen. An NSPP can also be deleted when an entire Batch is deleted on the Batches home screen; however, selecting the blue Mark as Ready button on the Batches screen only affects non-NSPP Remittances.
When an NSPP is marked as Ready and processed in Fiscal Overview > Unprocessed Remittances, the amount becomes an Unapplied Payment WITHOUT CHARGES and is included in the count of Unapplied Payments on the Fiscal Overview screen. Negative NSPPs become Takebacks; positive NSPPs become Overpayments.
Search for specific Unapplied Payments WITHOUT CHARGES by using the filters on the left to limit results. Use the blue MARK AS DONE button to update a single Unapplied Payment or select the checkboxes to use the bulk Mark as Done Action.
Default Payer for New Clients
An agency can now define one or more Default Payers for new Clients to help streamline the intake process. In Configuration > Services/Payers > Payers > Profile, there is now a Make Default for New Clients checkbox. Selecting this checkbox makes the Payer Priority field required. Two active default Client Payers cannot have the same Default Priority value assigned.
|
|
When a new Client’s record is saved, the configured default Payer(s) is added to the Client automatically. If the default Payer is not a SelfPay Payer and the Default Priority is 15, the Client Payer settings default to the following.
If the default Payer is a Selfpay Payer and the Default Priority is 99, the Client Payer settings default to the following
Service Facilities
Service Facility Locations can now be entered in Configuration > Setup > Organizations. When adding a new organization, a radio button for Organization Type, Billing Provider or Service Facility, must be selected, where the Billing Provider type is the default selection. A Service Facility Location should be defined when a payer requires that both a Billing Provider (Organization) and a Service Facility Location be reported. Location and Defined Filter fields are available to target the Service Facility Location to the correct Services and Payers because not all payers expect or accept Service Facility Locations.
After the Service Facility is saved, additional fields for Start Date, End Date, Location Number, NPI, Place of Service, and Defined Filter may be completed.
1. Start Date and End Date – Start and End Date may be optionally populated to define the Service Facility’s active date range.
2. Location Number – Optionally enter the assigned location number for this facility, 50-character maximum field.
3. NPI – Optionally enter the assigned National Provider Identification number for this location, 10-character maximum field.
4. Place of Service – Enter the Place of Service to report when the Defined Filter matches on a Service, required.
5. Defined Filter - Select the Defined Filter used to determine when to report this Service Facility’s Place of Service.
After the Service Facility is configured, navigate to Configuration > Services/Payers > Payers > Billing Methods, and select the Report Service Facility Location (Loop 2310C) checkbox on the 837P and the Report Service Facility Location (Loop 2310E) on the 837I for the necessary Payers.
|
|
Once the Service Facility Configuration is complete and an 837P/I Create Bills job is generated for a Payer configured to report the Service Facility, the 837P has the 2310C loop, and the 837I has the 2310E loop reported in the submission file. A sample from an 837I file is shown below.
A warning is generated if an 837P/I Create Bills job is run for a Payer that is configured to report the Service Facility, and a Service does not match any of the Service Facilities Defined Filters. The Charge is still billed with the 2310C loop or 2310E loop omitted.
If an 837P or I Create Bills job is run for a Payer configured to report the Service Facility and a Service matches more than one of the Service Facilities Defined Filters, the first match is reported. There is no warning or error generated.
Improvements
Report Permissions
The Reports column in Configuration > Staff/Users > Permissions > Reports Menu now defaults to open, making the full report path visible. This column can still be expanded/opened or collapsed/closed by clicking the empty header of the Reports column. This page now also correctly excludes all reports, including custom content, prefaced with an underscore.
Opening a Service in a New Tab
Updates were made to open a Service in a new tab or window when working in the Services grid. For example, now right-clicking on the Date displays the following options. Note that opening an incognito window (Chrome) lands on the EchoVantage login page, not the desired Service.
An update was also made to allow users to access the Service from the Claim Details screen. Now, the Service listed above the first Payer is a clickable link to the Service itself. Right-clicking on this Service allows users to open the Service in a new tab or window as above.
Code-Related Views
A review of how code-related items are maintained is in progress. As part of this planned improvement, views containing code-related information were reviewed and removed in some cases. The table below lists the removed views and the available alternatives. Any agency-created custom forms or reports that reference one of these removed views need to be updated once the upgrade to v3.31 is complete.
837P/I Improvements
Payer with No Error Free Claims in an 837P/I Create Bills Job (Support Case 6525)
The 837P/I file creation process was updated to exclude the 837P/I submission and debug files for Payers that did not have any error free claims included in the Fiscal Overview > Unprocessed Services > Create Bills job. Before this change, an 837P/I shell file was created that only contained the header and trailer, but no claims. It was difficult to differentiate these invalid files when a multi-Payer Create Bills job was run and led to some shell files being submitted to a Payer in error.
Now if all the claims in a single 837P/I job have errors, the 837P/I submission and debug files are empty. Similarly, if the claims for a single Payer, Payer X, in a multi-Payer job all have errors, the zip files do not contain the 837P/I (Submission or Debug) for Payer X. In both instances, the report is still visible.
In the case where all claims in the job have an error, there are still empty submission and debug zip files visible on the Create Bills History screen for now. A future improvement is planned to handle this eventuality.
Reporting Loop 2300 DTP Admission Date in the 837P
Updates were made to the 837P reporting process to now check for matching Enrollments in the same manner as in the 837I for reporting Loop 2300 DTP Admission Date when the Place of Service on a claim is 21,51, or 61. The Service Date and Program component is compared to the Client’s Enrollments to determine if there is a match. The Service Program must match on the Enrollment Program and the Enrollment must have been active for the Service Date.
- If the Service has a Place of Service that is 21, 51, or 61, and there is a matching Enrollment, then Loop 2300 DTP*435 is reported with the Enrollment Start Date.
- If the Service has a Place of Service that is 21, 51, or 61, and there is no matching Enrollment, the Loop 2300 DTP*435 is not reported and there is no error.
- If the Service does not have a location of 21, 51, or 61, Loop 2300 DTP*435 is not present. (Current Behavior)
Bug Fixes
Timeline Diagnoses (Support Case 1056)
An issue was reported where User Group members could add a new Client Diagnoses from the Timeline even when their user group did not have the Diagnosis edit permissions. As a result, a new Timeline Category was added in Configuration > Client Chart > VHR Timeline entitled Client Diagnoses which points to a read-only version of the Client Diagnoses form to address the issue. In the Header Editor, access to this read-only version can be assigned by User Group and gives a non-editable option for User Group members that need the ability to view Diagnoses but not add or edit. Please note that User Group access to this new read-only form is not granted to any User Group by default.
On the Client’s Timeline, this new read-only category does not display the green “+” plus button on the Timeline like the original version. The image below is the view of a user with access to both Client Diagnoses forms with both forms configured to appear in the Client Diagnoses Header.
Improved Functionality with MEND
Duplicate Email Check
A check was added to ensure that the email address is unique for the Client, Staff, or Ward before the address is passed to Mend when creating an Event or Service. Mend uses the email address as their unique Client identifier. Previously, if the email address was already attached to a different Client, Staff, or Ward in Mend, the Telemedicine Session for the new Event/Service was created for the existing Mend Patient or Provider rather than the Client or Staff on the newly created Event in EchoVantage. With this added check, if multiple Staff have the same email address or multiple Clients have the same email address, an error is thrown indicating a Duplicate Email Address when attempting to create a Telemed Event. The duplicate email address must be corrected before a Telemedicine session is successfully created. Examples of these error messages are below.
|
|
These new errors do not interfere with creating a Telemed appointment for a ward or a Client under the minimum age specified in the Portal. In addition, while a Ward does not need their own email address for a Telemedicine appointment, if they do have one, it cannot be the same as their Telemed Contact’s email address.
Invalid Email Addresses
An issue was addressed where an email address with a leading space triggered an Internal Server Error. The problem was addressed by trimming any leading or trailing spaces from Staff, Client, or Client Contact (Telemed Contact) emails. Additional error handling was also included. An invalid email address now returns one of the following errors.
Updates
|
Ticket # |
Description |
|
EV-1598 |
Updates were made to prevent multiple actions when the SAVE button is clicked two or more times in quick succession. The following areas of the application were addressed.
|
|
EV-1803 |
How the report parameter caching is handled was changed to prevent a time-out with many custom reports. The first request is now nearly instantaneous instead of taking minutes to complete. |
|
EV-1944 |
The Staff grid on the Clients > Episodes tab is now sorted to make finding the active Staff for the selected Episode easier. The sort order is based on the following rules.
|
|
EV-1974 |
An update was made on the Service Definition page that prevents the entry of a negative Base Rate. |
Bug Fixes
|
Ticket # |
Case # |
Description |
|
EV-575 |
|
An issue was reported where, under certain conditions, more than one Billing address could be active at the same time for a Client. As a result, the Client Contact Information (Client Communication) form was updated to prevent more than one active billing address unless the active dates (Start Date and End Date) do not overlap. |
|
EV-1281 |
|
An issue was addressed where the Recipient drop-down list for Client Type messages in the Inbox displayed Clients that did not have access to the Client Portal. As a result, if a message was sent to a Client without Portal access, the Client did not receive the message, and there was no warning or indication that the message was not delivered. The issue was resolved by limiting the Recipient drop-down list for Client Type messages to only those clients with access to the Client Portal enabled. |
|
EV-1689 |
|
An issue was addressed when editing an Authorization in Clients > Payers by changing the type from dollar to unit failed validation because the two decimal places from the dollar validation were still added. Now when an authorization is edited, and the type is changed from dollar to unit OR unit to dollar, the Amount field is cleared to prevent validation errors. |
|
EV-1739 |
|
An issue was addressed where trying to create a Per Diem Telemed Service crashed the system. The TelemedEligibility column is automatically set to ‘N’ when saving a Per Diem Service to prevent future occurrences. |
|
EV-1906 |
|
The Organization Pay-To Address now displays the 4-digit zip extension. Before this change, entry of the zip extension was required but was never displayed in Configuration > Setup > Organizations. |
|
EV-1927 |
|
An issue was addressed where the Clients > Account tab handled an Unfinalized Client Payment Remittance differently than the Claims Management menu. The Current Balance amount on the Client’s Account tab included the unfinalized Remittance amount. In contrast, the Claims Management menu did not include the Remittance until it was finalized, resulting in the two balances being out of sync. Updates were made to the Client > Account Current Balance so that it no longer includes Remittances in Preview status. |
|
EV-1947 |
|
An issue was reported when deleting a Remittance from the Remittances > Remittances screen returned the user to the Remittances > Batches screen. The incorrect redirect was addressed, and now when a Remittance is deleted in the original Remittances screen, the user is not redirected to the Batches screen. |
|
EV-2030 |
|
The formatting on the InForms Trial popup message in Configuration > Staff/Users > Permissions was updated to display in the new Permissions layout introduced in v3.30 correctly. |
|
EV-2075 |
|
An issue was addressed where the DELETE button was available on a new, unsaved Insight in Configuration > Setup > Insights, resulting in an ‘Unexpected Error’ if selected. The issue was addressed by not enabling the DELETE button until after the new Insight is saved. |