Version 3.37, Released May 19, 2022    ** Updated May 27, 2022**                                                                                           Previous Release Notes

v3.37-Hotfix 1 Release Notes

v3.37-Hotfix 2 Release Notes

New Features

Unmatched Payments

Unmatched payments is the term used by Echo for non-specific payer payments that do not have a matching charge but are specific to a client and date of service. These payments may be in error, possibly due to a billing mistake, and this feature allows the agency to account for the payment while keeping track of the associated client and service date until the details of how it will be handled are sorted.

The upgrade creates a new user-defined payment transaction definition, Unmatched Payment, with the value of NON in the UserTransactionDefinition column of the TransactionDefinitions table. Like custom denial types, your agency can create additional non-specific payer transaction definitions to further track these types of payments provided that the UserTransactionDefinition value is NON. Click HERE for more information on Remittance Transaction Types. 

When importing a payment from an 835, an unmatched payment is created in Not Ready status when the payment is for a VOID charge (not a VOID REQUEST) and no new charge exists for the same client and date of service. The 835 may contain an Id837 from one of the void charges or a non-matching Id837. These Not Ready payments include Payment Amount, PCCN, Payer, Client, and Service Date, as shown below.

If manually entering an NSPP (Non-Specific Payer Payment) in Remittances > Batches or original Remittances, the new Unmatched Payment option is available in the Type drop-down list. When the transaction type is NON SPECIFIC PAYER PAYMENT or Unmatched Payment, the PCCN, Client, and Service Date can be recorded but no cards display to associate a charge.

Remittances > Batches
Remittances > Remittances

When an Unmatched Payment type Remittance is associated with a Client and Service Date AND finalized in a Fiscal Overview > Unprocessed Remittances > Process Transactions job, it is displayed in the Unmatched Payment section of the newly restyled Claim Details modal. The same unmatched payment displays for each claim that matches both the Client and Service Date.

The payment becomes a Without Charges type of Unapplied Payment, as either an Overpayment or a Takeback, in Fiscal Overview > Unapplied Charges. Clicking on the blue VIEW UNMATCHED PAYMENTS button in Claim Details opens the Unapplied Payments > Without Charges > Takeback or Overpayment page with filters for the associated Client and Date of Service applied.

In Fiscal Overview > Unapplied Payments > Without Charges, the payment can be marked as DONE or REFUNDED just as before OR REVERSED which removes the payment from the Unapplied Default GL accounts.

Reversing the unmatched payment clears it from the Unmatched Payments section of the Claim Details screen.

Reversing the unmatched payment also creates a copy remittance with a status of Reprocessed.

The following two sections document the workflow for using the Reprocessed remittance to create a Payer Payment.

Applying the Reversed Unmatched Payment in Remittances > (Legacy) Remittances

A second, separate copy remittance with a status of Reprocessed is created by the reversing action. If the original unmatched payment was entered via the legacy Remittances page, the copy remittance may be located by searching for remittances with a Status of Reprocessed for the associated Client and Service Date. Then select the reprocessed remittance to open the Edit Remittance screen.

1. Change the Status to Not Ready and select SAVE.

2. Change the Transaction Type to Payer Payment.

3. Then locate the appropriate Charge on the now visible cards, and select the radio button to associate the payment.

4. Change the Status to Ready and select SAVE again or leave Not Ready if marking items in bulk.

The payment is now ready for the next Process Transactions job in Fiscal Overview > Unprocessed Remittances.

Applying the Reversed Unmatched Payment in Remittances > Batches

When the original Unmatched Payment is entered via Batches, the copy remittance is added to that same batch. If the associated batch information is not already known, locate the Reprocessed remittance in the legacy screen and select the row.

Then select the blue View in Batch button to view the selected reprocessed remittance in the batch. Note that batches do not display Done or Voided transactions so the original Unmatched Payment transaction does not show.

1. The reprocessed (copy) remittance can remain untouched for now.

• Batches use a separate form for NSPP type payments so the reprocessed remittance cannot be converted to a Payer Payment as on the legacy Remittances page.
• The ability to delete a remittance with the Reprocessed status will be available with the release of v3.38.

2. Add a new row to the batch for a payer payment transaction type for the same amount as the original Unmatched Payment.

3. The newly added Payer Payment is now ready for the next Process Transactions job in Fiscal Overview > Unprocessed Remittances. The reprocessed remittance can be deleted in a future release.

Family Ability to Pay

The new Family Ability to Pay feature allows the agency to define the maximum amount a family should pay, the interval to which this amount applies (monthly or yearly), and the active date range for the amount in the Families main menu option under ABILITY TO PAY.

In the Families > ABILITY TO PAY tab,

• Multiple rows may be added as long as the active date range, defined by the Start and End Dates, does not overlap.

• The rows are sorted by Start Date, descending.

• Audit views are available for this tab in Configuration > Setup > Audit.

  • Track Changes

    

  • Track Views

    

In addition, for a family member's charges to be included in the calculation, the Family Maximum Client Fee type must be configured in the Clients > Payers screen for the self-pay payer. A Defined Filter can be used to limit which Services/Charges count toward the maximum.

• If Family Maximum is selected for the Client Fee Type, and the Client is NOT a member of a Family.

  • A No Family Configured for the Client warning banner displays.

  • 

  • The banner has an Add Family button that takes you to the client’s Family tab when selected.

• If Family Maximum is selected for the Client Fee Type, and the Client IS a member of a Family,

  • A Family drop-down list is available, populated with the Families of which the Client is a member.

  • 

  • If the selected family does not have an Ability to Pay record configured, an Ability to Pay for this Family has not been Configured notice banner displays.

  • 

  • This info banner also has a CONFIGURE button that takes you to the selected Family with the Ability to Pay tab in focus.

• Remember, once a Client Fee is configured for a Client, it can be end-dated but not deleted.

After the Add Client Fee entry is saved for a Family Maximum fee Type, a row displays in the Client Fees section of the self-pay Payer. The following text displays in the Amount field in place of a dollar value -Calculated from Family Ability to Pay.

• Use care when assigning the Family Maximum Client Fee Type, as the delete icon is disabled for Family Members with this fee type assigned.

• Hovering over the disabled icon displays the following message ‘Cannot delete Member with a Family Maximum Client Fee for this Family’.

• In place of deleting, a Family Member can be hidden from the list of Clients if they are made inactive.

  • Select the Client row to open the Edit Family Member screen.

  • Enter a value for the End Date.

  • Slide the Show Inactive Members toggle to the left to hide the end-dated Clients.

• When these two pieces of information are configured, the create charges process takes into account the value of existing self-pay charges, including the current charge and the defined filter if any, for the family members, and writes off any balance that exceeds the family’s Ability to Pay amount.

• The job processor, oak, throws an error if

  • The Client is configured with a Family Maximum but is not a member of a Family.

  • Or the Client is a member of a Family but the defined Ability to Pay amount for that Family is not active as of the Service Date being processed.

---

Improvements

Excluding Self-Pay Charges When Setting Status to Working

The process for halting the waterfall and setting a charge status to Working was updated to exclude all self-pay charges, as these charges do not waterfall and are always held open until the final payment or adjustment is made. This change also updates any self-pay charge status to Active if it currently has a Working status since the Rebill action in Claims Management does not apply to self-pay charges. The Minimum Days Elapsed setting in Configuration > Services/Payers > Self-Pay Payer > Billing Methods determines the frequency for which client statements are available to print, controlling how often a self-pay balance is billed.

Preventing the Individual Reprocessing of Previously Bundled Services

An additional check was added to determine if selected service(s) were part of a bundle for a prior Payer when attempting to Reverse Service Transactions or Reprocess All Payers in the Claims menu. If any of the selected services were part of a bundle, but all the services associated with that bundle are not included in the reprocessing job, an additional message now displays in a secondary modal after confirming the reversing or reprocessing job. The example below details how this additional check works.

A Client has Payer 1 (ANTHBCBS) which accepts bundling and Payer 2 (CC01) which does NOT accept bundling. The Client receives four services that are billed in a monthly bundle to Payer 1 on May 3, 2022.

Payer 1 responds with a partial payment of $75.00. When the remittance transaction is processed and finalized, the remaining balance waterfalls to Payer 2. Once the waterfall Create Charges job is finalized, the services are “unbundled” and charges for Payer 2 are created for each of the services.

As shown in the image above, there is no indication that these four services were previously bundled. Now suppose that just one of the four services is selected for a Reverse Service Transactions (or Reprocess All Payers) job as shown below.

After the CONTINUE WITH SELECTION button is selected, a Reverse Service Transactions job modal displays.

The additional check is performed after the REVERSE button is selected. Since the selected service in the job above was previously part of a bundle, the check finds the other three services that were not included in the job and displays this information in a second, separate Extra Services modal.

The message indicates that Some of the selected Services have been or are currently bundled. In order to reverse, an additional 3 Service(s) will be reversed. Click CONTINUE to proceed with the reversing /reprocessing job or select CANCEL to return to the Claims menu without making any changes. If CONTINUE is selected, all four services show in the reversing job on the Claims > History tab.

Additional Report Date for Service Bundling Options

In Configuration > Services/Payers > Service Definitions, two new Report Date for Service options are available for bundled Service Definitions that have a Frequency of Monthly or Weekly which allow a date range to be reported when the following Billing Methods are used.

• 837P (Loop 2400 DTP*472)

• 837I (Loop 2300 DTP*434, Loop 2400 DTP*472)

• CMS1500

• UB04

These new options are: First and Last day of the month (week), and First Service Date and Last Service Date of the month (week).

Monthly	Weekly

For example, suppose a Client receives the following Services for the month of April.

These services meet the bundling requirements of the following Service Definition that has a Monthly Frequency and the First and Last day of the month for the Report Date for Service option.

When a bill is created for the bundled charge, the date range reported is 04/01/2022 - 04/30/2022. Excerpts of the date segments from the 837P and 837I bills are shown below.

837P	[L.2000C!L.2300!L.2400]DTP*472*RD8*20220401-20220430
837I	[L.2000C!L.2300]DTP*434*RD8*20220401-20220430 [L.2000C!L.2300!L.2400]DTP*472*RD8*20220401-20220430

Now suppose that the Service Definition was updated to use the First Service Date and Last Service Date of the month option for this same monthly bundle.

If the same Client and Services are billed, the date range now reported is 04/03/2022 to 04/25/2022.

837P	[L.2000C!L.2300!L.2400]DTP*472*RD8*20220403-20220425
837I	[L.2000C!L.2300]DTP*434*RD8*20220403-20220425 [L.2000C!L.2300!L.2400]DTP*472*RD8*20220403-20220425

Restyled Claim Details Modal

In addition to adding the Unmatched Payment section, the Claim Details modal was restyled and includes additional links for quick access to other parts of the application. The updated modal and links are listed below.

1. The Client Code and Name is a clickable link to the Clients main menu option. The user is taken to the first tab to which they have access.

2. The date of Service, billing code, and Service Name information are listed just below the Client Code and Name and link directly to the associated Service.

3. Click the NOTES & TASKS button to access the related Claim note and task information.

4. A VIEW CLIENT button was added. Selecting this brings the user to the first Client tab to which they have access.

5. A VIEW CLIENT PAYERS button was added. Selecting this brings the user to the Payers page of the Client in focus with the highest priority Payer in focus.

6. Links to specific Client Payers were added. Selecting a Payer’s name brings the user to that specific Client Payer in the Clients menu.

7. Use the new blue note icon to view that specific Payer’s address and phone number information as found in Configuration > Services/Payers > Payers > Communication.

• If the Payer’s Communication tab has information, the most recent, active address and telephone information is displayed.
• 
• If the Payer’s Communication tab is not populated, a blue +ADD button is available to optionally enter the missing information.
• 

Payment Field Validation Increased in Remittances

The Payment field validation in Remittances > Batches > View Batch > Add/Edit Row and Remittances > Remittances > New/Edit Remittance were updated to allow amounts up to 999,999,999.99 before triggering an error. This new validation amount is consistent with the maximum allowed while importing the payment amount in the SVC segment of the 835-file.

Before	After

---

Reports

The following Fiscal Reports were updated.

Cash Receipts Journal - This report was displaying an incorrect received amount, particularly when a Client Payment was applied to multiple charges. The query was updated and the received amount now displays correctly.

_Cash Receipts Journal For Export - The same updates were applied to this csv friendly version of the report above.

---

Updates

Ticket Number	Description
EV-1428	An issue was found when working on a smaller screen (laptop) where the Payer drop-down in the Remittances > Batches > View Batch > Add/Edit Row screen opened behind the Client drop-down. This behavior made it difficult to scroll the Payer list and make a selection. The issue was addressed and now the Payer drop-down list is scrollable and making a selection is not impeded regardless of screen size.
EV-1599	In the Members section of the Families main menu option, the method used to display the information in the Labels column was updated. Now multiple labels are always visible when there is sufficient space for the full label text to display. When there is not sufficient space, the labels are collapsed into a chip showing the count of the labels. Clicking on the chip displays the list of labels in a popover.
EV-3498	Validation was added to prevent the entry of alpha characters in the Minimum Minutes and Maximum Minutes Service Duration fields when copying a Charge Calculation in Configuration > Services/Payers > Service Definitions or Payers > Rates. The field does not accept the entry of non-numeric values and remains blank.
EV-3499	On the Create User screen in Configuration > Staff/Users > Supplemental Users, the Email Address field is now validated for a valid email address format and a maximum length of 50 characters. The following error displays until the email address is properly formatted - The email format is invalid. Text entry is prohibited after the maximum characters are entered.
EV-3519	The REQUEST VOID button and associated help icon are now hidden from view for all self-pay/client payments.
EV-3560	Updates were made to how the Payer and Client addresses are chosen when CMS-1500 or UB-04 bills are created. The most recent active payer address is reported on the CMS-1500. The client address where Billing = 'Y' is reported for all claims on both the CMS-1500 and UB-04. The most recent active client phone number is reported for all claims on the CMS-1500.
EV-3575	The void status, if requested or sent, is now visible for unapplied payments in the Claim Details screen. “Unapplied” Unapplied Payment    Void Requested Unapplied Payment   Void Sent Unapplied Payment
EV-3634	Updates were made to the grid displayed on the Eligibilty > Requests screen to prevent the table from being misaligned due to a long Rejection Reason. Now when the rejection reason exceeds 30 characters, the message is truncated and an ellipsis (three dots) displays, allowing the grid to stay aligned. Hover the cursor over the reason to display the full message in a box view. After Update Before Update

---

Bug Fixes

Ticket Number	Case Number	Description
EV-3497		An issue was found where the message field blue line overlapped the recipient drop-down list values when composing a message for a form. The issue was addressed and there is no longer a line through the drop-down list values.
EV-3582		The 270 download toast was updated to say File will be available in Downloads when the job completes. Previously the toast directed users to the Downloads tab of the Message Center.
EV-3630		The item count on the Select All checkbox was updated in the Unapplied Payments > Without Charges section to only include the count of items for the currently selected tab, either Takeback or Overpayment. Previously the Select All count combined the values from both tabs.
EV-3679	12410 12683	An issue was reported where the Message notification dot would sometimes require a refresh, or logging out and back into the application, before displaying. The cause was due to not reconnecting to the push notification service, beech after it was restarted before the retry interval expired. The issue was addressed by increasing the interval for the retry attempts.
EV-3717		An issue was found where marking an item in Unapplied Payments as Refunded resulted in two jobs in the database and two toast messages - one successful and one failed. The query was updated and now marking an Unapplied Payment item as Refunded only results in one job.
EV-3728	12473	An issue was reported where alerts could fail to load and the manual refresh remained disabled when multiple alerts were opened in separate tabs. While researching it was discovered that the failures were due to expensive custom alert queries. While custom queries are outside the control of the application, the alerts fetching process was updated so that if a failure occurs, the manual refresh button is enabled and can be used to update the list.
EV-3782		An issue was reported where the POS Mappings in Configuration > Services/Payers persisted across Payers when moving from a Payer that had mappings to one that did not. The issue was addressed by ensuring the POS Mappings page refreshes before being displayed for the newly selected Payer.
EV-3783		An issue was reported where Batches that contained a Non-Specific Payer Payments or Unmatched Payments could not be marked as READY from the Batches screen, even though all transactions within the batch could successfully be marked READY from the View Batch or Edit Row screens. The issue was addressed and now marking Remittances as READY is successfully for batches that contain NSPPs or Unmatched Payments.
EV-3792	11908 12938	An issue was reported where the recurring time slot on a staff’s schedule in Configuration > Staff/Users > Staff Schedules could not be completely cleared - SAVE was disabled if more than four days were cleared. This issue was addressed with the following updates. If a recurring schedule is already set, all days can be removed and the SAVE button is enabled. If a Staff member is scheduled on weekdays during the next month and Set Schedule is selected for that staff with valid Start and End dates for the second week of the next month, then the SAVE button is enabled. When SAVE is selected, the modal closes, and the schedule is cleared for the date range (Start and End dates) entered.
EV-3829		An issue was reported where the toggle between Locations and Defined Filters was not functioning in Configuration > Services/Payers > Payers > POS Mappings when no mappings exist. The issue was corrected and now the toggle works whether mappings are or are not present.
EV-3883	13179	An issue was reported where client Copay Charges were not calculated correctly when the Client had a single commercial payer and the self-pay payer. The issue was addressed and now the balance of the self-pay charge is equal to the defined copay in Clients > Payers when there are no other commercial Payers.