EchoVantage Release Notes History

Version 3.30, Released October 29, 2021                                                                                                                                     Previous Release Notes

New Features

Client Payment for an Event

A new Apply Payment To option, Scheduled Event, is available when posting a payment on the Clients > Account tab. When this new option is selected, Event Date and Event fields display. The drop-down for the Event field is validated and only lists scheduled Events for the current Client based on the Event Date selected.

Once saved, the Client Payment is then allocated to the selected event and remains attached until,

• The Client Payment is fully applied to the Self Pay Charge resulting from the Service related to the event. The Client Status is updated to Applied on the Clients > Account tab.
• The Client Payment is partially applied, and the Service created from the specified event has a Status of DONE.
  • The Client Payment remains in Pending Status until the associated Services has a DONE Status.
  • After the Service is set to DONE and the APPLY_CLIENT_PAYMENTS job runs again, the Client Payment Apply To type is updated to Specific Service in place of Scheduled Event.
  • The remaining amount is available to apply in the Client Payments > Apply Payments tab when the Client has an Active or Outgoing Self Pay balance.
• The event is deleted.
  • A warning displays if deleting an Event with an allocated Client Payment.
  • 
  • If the Event deletion is confirmed, the allocated payment becomes an apply to Specific Services type of Client Payment, as above.

Once a Client Payment is allocated to an Event, and a Self Pay Charge related to that event is generated, the APPLY_CLIENT_PAYMENTS job (which typically runs on the hour) automatically applies the Client Payment and generates a Ready Remittance. This automated process means no remembering to apply the Client's payment after Charges are created. An example that works through the entire process is detailed below.

Example, Clients with Defined Copays

Raymond Avila and Debra Bailey are scheduled in the same Group Therapy Event.

These two Clients have the following Payer, Account, and Payment information.

Client	Current Account Balance	Primary Payer	Expected Self Pay Charge	Client Payment Amount
Raymond Avila	$0.00	837 Payer	$10.00 Flat Copay	$10.00
Debra Bailey	$40.00	837 Payer	20% of Base Copay ($30)	$70.00

The $10.00 payment is posted for Raymond Avila, and Scheduled Event is selected in the Apply Payment To section.

The $70.00 payment is posted for Debra Bailey, and again Scheduled event is selected with both the Event Date and Event fields populated.

The Clients attend the group therapy appointment, and the Client Payments are reconciled at the end of the day.

 

Later that evening, Charges are Created and Finalized for these two Group Event Participants.

 

Copay Charges for Self Pay for each Client are calculated during Charge Creation because both have the copay configured on their 837 Payer in Clients > Payer. When the APPLY_CLIENT_PAYMENTS job runs again (typically on the hour), a Ready Remittance is created for each Client, as shown below.

 

---

Note that Debra Bailey's Remittance amount is $30.00 and is the same amount as the Self Pay Charge associated with the event selected when the Client Payment was entered. The total Client Payment amount was $70.00, which means there is still an unallocated Client Payment amount of $40.00 associated with the Group Therapy Event on 10/20/2021. This unallocated amount remains in Pending Status until the Service Status is DONE. Handling the remainder is covered at the end of this section.

---

These Ready Remittances are included in the next Fiscal Overview > Unprocessed Remittances > Process Transactions job for Self Pay.

 

When the Process Transactions job above is finalized, the copays are applied to the correct transaction without any extra steps after collecting the initial payments.

Raymond Avila Claim Details

 

Debra Bailey's Claim Details

 

The Account tab for each Client is also updated. Raymond Avila's Account tab displays a balance of $0.00, and his Client Payment record now displays the Applied icon.

Debra Bailey's Account tab displays a balance of $40.00 but her Client Payment record still has the Pending icon because the full $70.00 Client Payment is not yet applied.

Payment for the Copay for the 10/20/2021 Service has been fully applied (Client Balance is $0.00 for the highlighted Service below.), but the remainder of Debra's Client Payment, $40.00, stays in Pending Status until the Service Status is DONE. In the example below, the Payer has not yet responded, and the Service Status is still Charge Created.

After the Payer responds and the payment is posted with any necessary adjustments, both the Charge Status and the Service Status are updated to DONE, example below.

Once the Service is DONE, the next time the APPLY_CLIENT_PAYMENTS job runs, the $70.00 Client Payment's Apply To type is updated from Scheduled Event to Specific Services.

Before Job Runs
After Job Runs

And the remaining amount is available to apply in the Client Payments > APPLY PAYMENTS screen.

When the entire $40.00 remainder is allocated and applied, the Status icon on Debra's Client Account tab is updated to Applied.

Although this example uses Copays defined on the Client's Payer to generate the Self Pay balances, any method of generating a Self Pay balance works provided the Service generating the Charge was created from the event defined on the Client Payment's Apply To section. Some agencies may choose to wait until the Payer responds with payment and then accept the amount the Payer indicates as the Patient Responsibility to waterfall to Self Pay. When this happens, the Client Payment for a Scheduled Event remains in Pending Status until the APPLY_CLIENT_PAYMENTS job runs after the waterfall to Self Pay Create Charges job is finalized.

Example, Waterfall Creates Self Pay Balance

Cassandra Allen has an Anger Management appointment scheduled for 10/21/2021. She pays $20.00 when she checks in, which is entered on her Clients > Account tab and applied to the 10/21/2021 appointment.

 

The Client Payment is marked Ready and reconciled, and a Charge is created for the Service created from the event. Cassandra's Current Balance is $0.00.

 

A Remittance is entered for the created Charge, an amount of $20.00 is entered as the Patient Responsibility, and the Remittance is processed.

Then the Waterfall to Self Pay Create Charges job is finalized.

 

Cassandra's Current Balance on the Clients > Account tab is now $20.00.

 

Once the APPLY_CLIENT_PAYMENTS job runs after the Waterfall Charge is Finalized, the Pending $20.00 Client Payment becomes a Ready Remittance.

And the Clients > Account tab immediately reflects this Ready Remittance.

Client Account Improvements

Several updates to the Clients > Account tab are also included in this release and provide additional configuration options and details regarding Client Account Payments. These changes include:

• The Client Account tab can now be designated as Read Only.

  • Define menu access in Configuration > Staff/Users > User Group > Menu Access.
  • Existing access to Accounts remains unchanged, so Read Only must be specified for the applicable groups.
  • Users with Read Only access can View Payments and Payment details and Print Receipts.
  • Users with Read Only access can NOT add a new payment or Void an existing payment.
• An Apply To column was added to indicate the type of Client Payment, and the Receipt Number and Print Receipt columns were combined to make room for a new icon column.

• The icons indicate the status or stage of the process of each Client Payment.

• Select any Client Payment row to view details about the Payment.
• Pending, Void, and Applied payment records open a read-only details screen.
• A new, unreconciled payment record opens an editable details screen.

Important Considerations and Future Improvements

On the Clients > Account tab, as soon as all or a portion of the Client Payment becomes a Ready Remittance, the displayed Client (Self Pay) balance is reduced by the new Ready Remittance amount, and the icon indicates the Client Payment was "Applied" on the Remittance creation date. However, the Claims Management screen and the Claim Details screens do not reflect the Remittance amount until it is Processed AND Finalized. If comparing the Client Account tab balance to the Claims Client Balance, remember that unprocessed Remittances affect each balance differently.

Future improvements are planned to expand the Status icons so that the stages of the Client Payments are more clearly defined. These improvements include,

• An additional icon to differentiate between the Applied - Remittance Ready and Applied - Remittance Finalized.
• Additional Pending status messages to define Pending Job, Pending Self Pay Balance, Pending Allocation.

Another important factor affecting Client Account Balance is a Client Payment Remittance in a job that remains in PREVIEW status. A Client Payment Remittance in an unfinalized job is in the transition phase of becoming a new Payment in the dbo.Payments table. At this point, both the Ready Remittance and the unfinalized Payment exist, so both are deducted from the Client Account Balance total resulting in it being understated until the job is finalized. Updates to how the Client Balance is calculated are planned for a future release.

---

Improvements

Batch Remittances Updates

Updates to the Batch Remittances feature are included in this release to streamline the workflow and expand the functionality of the Batches feature. Users can now

• Delete a batch
• Bulk delete rows within a batch
• Bulk change the status of rows within a batch
• Filter rows by the Payment amount and status (previously only Service Date and Client were available)

Deleting a Batch

A delete option is now available on the edit batch screen. Users can delete a batch when all remittances within the batch are in Ready or Not Ready Status, not previously processed. When DELETE is selected, a confirmation box displays; select DELETE again to confirm and delete the batch. When complete, a green success message displays in the upper right-hand corner.

If any of the Remittances in the selected batch have been processed, a warning message displays at the top of the Edit Batch screen, and the DELETE button is disabled.

Batch Remittances Bulk Actions

The new Bulk Actions are available on the View Batch screen. Checkboxes are available to select/deselect for each record with a select all/deselect all checkbox above the Status column. Once the records are selected, click the Action box on the bottom right-hand corner to select the desired action and enable the blue APPLY button. There are three available Actions to select.

• Mark Ready
• Mark Not Ready
• Delete

Filter Rows by the Payment Amount and Status

Also added to the View Batch screen is the ability to filter a batch by Payment Amount and Status. These new filters are in the grey section on the left-hand side and simplify finding specific records in large batches. Using the same batch pictured above, a Status filter of Not Ready is applied and reduces the number of records displayed from eight to two.

835 Import Improvements

The 835-import process can now match Charges when the Payer supplies only the Date Range Qualifier, DTM*150/151, instead of the Service Date Qualifier, DTM*472, and the Reference Identification Qualifier, REF*6R. Previously the Date Range Qualifier segments were not recognized by the 835 import process. The result was that all payments for Services across a date range were applied to the first Service because the referenced date range was at the Claim Level instead of the Service Level.  The 835-import process now recognizes the Date Range Qualifier (DTM*150/151) and uses that when the REF*6R segment is not provided. The Payments now apply to each Service, rather than just the first Service in the date range, as shown below.

View Past Services with Diagnosis by Defined Filter Enabled

Updates were made to the Service Entry screen to ensure that the diagnosis still displays on past Services even with the Filter Diagnosis by Program option enabled in Configuration > Setup > Service Entry. Before this update, if the Service diagnosis did not match the available options after being filtered by Program, no diagnosis was visible even though the information was stored in the database.

Services Screen Bulk Actions Permissions

A new Features permission, Services: Bulk Actions, is available in Configuration > Staff/Users > Permissions. This new user group permission controls the access to the Bulk Actions of marking Services as Ready and Deleting Services and is enabled by default to maintain existing functionality. This new permission affects the Services screen only but requires at least one of the Services: Change Status or Services: Delete features permissions enabled for the bulk action buttons to display.

When the Services: Bulk Actions, Services: Change Status, and Services: Delete permissions are all enabled, user group members see checkboxes to the left of status, and Mark Ready, Delete, and Bulk Actions above the column headings on the Services screen.

If a user has the Services: Bulk Actions permission enabled and only Services: Change Status enabled, then the Delete icon is missing and the Delete option in Bulk Actions is not visible.

Like the example above, when a user has the Services: Bulk Actions permission enabled and only Services: Delete enabled, then the MARK READY button is missing and the

When this permission is disabled, the checkboxes and actions above the column headings are no longer visible.

User Group members with permission enabled for the Services: Change Status and Services: Delete AND the Services: Bulk Actions disabled, can still update the status, or delete a specific Service when working in the Service Entry screen.

Updating Events After Service Creation

Updates to allow editing of Service Events or Group Events even after a Service is created, marked as Ready, and billed are included in this release. Users can change any Service or Group Event field, including the Client, except for the Group on a Group Event. While these Service/Group Events may be updated, they cannot be deleted if a Service exists for the Client or any Group member. Modifying a Service/Group Event does not create a second Service when saved. The colors of the Events and Services on the Scheduler remain the same, blue for an Event, grey with a lock icon for a Service, and the progress note icons remain unaffected.

When a Service is selected on the Scheduler in Clinical Home or Client menu, a left arrow displays in the header of the Edit Service screen that links back to the Service Type Event. Group Events had this functionality previously and already began on the Edit Scheduled Event screen when selected. Selecting this arrow opens the Edit Scheduled Event screen.

When the updates are completed, select the blue VIEW SERVICE button to return to the Service.

If updates are made to any Event in a series and SAVE is selected, the user must choose which Events require updating.

Activity Filtering Limited to Active Service Definitions

Updates were made to ensure only activities associated with Service Definitions that are active as of the Service Date are considered when the Only show Activities for the selected Program Service Component Option is selected in Configuration > Setup > Service Entry. Only active Service Definitions are considered before any filtering is applied based on the selected Program in the Service Entry screen.

For a simplified example, an agency has only two Service Definitions, as shown below.

Service Definition	Start Date	End Date	Program Component	Activity Component
ADP	None	None	ADP	ADP
ACE	None	None	None	ACE

When a Service is entered for today with ADP selected for Program, two values are available in the Activity(Service) drop-down.

If the ACE Service Definition is end-dated yesterday or given a start date of tomorrow, and ADP is again selected for a Service scheduled today, only one option is available in the Activity drop-down.

Form Sort Order in Echo InForms

Updates were made for the selected forms to always appear on the Device, Client Portal, or Email Link in the same order as they appeared in the Share Forms screen from the Client header. In addition, this order is consistent every time the Share Forms screen is opened until the forms are cleared. For example, forms are selected for client Sandy Beach in the Share Forms screen in the image below.

The forms then display in this exact order on the agency device.

Password Reset/Informs Link Emails

The validated email address for Send Password Reset Email from: on the Configuration > Setup > Client Engagement > CLIENT PORTAL tab and the Send InForms Link Email from: on the Client Engagement > INFORMS tab was changed to noreply@echoehr.info. This new address is updated during the upgrade process for SaaS-hosted customers. Just as before, any change to this address prompts the following warning.

Code Updates

The Vaccination National Drug Codes were updated in the master codes table, dbo.Codes. As part of this update, the names displayed are now the proprietary names rather than the generic names of the vaccines. A review of any custom vaccination forms is recommended to ensure that these updated codes correctly display.

The three specific Value Sets listed below were affected by the update.

• 2.16.840.1.113883.3.3802.12.4.5 – Vaccine Codes
• 2.16.840.1.114222.4.11.826 – Vaccine Manufacturer
• 2.16.840.1.114222.4.11.934 – Vaccines Administered

---

Reports

Updated Reports

The following reports were updated.

Administration Reports

Enrollment Census Report – Updates were made to correct the Length of Stay calculation. Now, when there is discharge data, the difference between the start date of the enrollment and the discharge date is used to determine the Length of Stay. If there is no discharge date, the difference between the start date of the enrollment and the end date specified in the report filter is used to determine the Length of Stay.

---

Updates

Ticket #	Description
EV-1449	Updates were made to the Search For Next Available (SFNA) feature to consider the Resource's Start and End dates when specified in the filter criteria. Now, if a search is performed across a date range and the specified Resource is only available for a portion of the range, results are only returned for the dates where the Resource is active. In addition, if the selected Resource has a Start Date, End Date, or both, these dates are now displayed on the resource label.
EV-1718	A Client's age is now displayed in the Client header based on the date of birth entered on the Clients > Profile screen and the current date.
EV-1786	Updates were made to the search on the Rates page in Configuration > Services/Payers > Payers to improve the search performance. The search no longer repeats with each character typed in the search field, which was the cause of the delay in seeing the filtered results.
EV-1809	The description of the Only show Services for the selected Program Service Component Option in Configuration > Setup > Service Entry was updated to provide more clarity. The following text was added, "Services from Service Definitions for which no Programs have been defined will also be included."

 Bug Fixes

Ticket #	Case #	Description
EV-73		An issue was addressed where the Rates page in both Configuration > Services/Payers > Service Definitions and Payers allowed the entry of negative values for Credentialed Rates. The Base and Contract Rates on both screens are now validated, and the following message displays if a negative rate is entered "Rates cannot be negative."
EV-578		An issue was addressed where a Client Payment could not be assigned in Client Payments > Apply Payments if the Service/Charge did not have a Program. The Client and Payment appeared, but the Service/Charge information did not populate. The issue was addressed, and now a Client Payment can be allocated to a Service that did not have a Program.
EV-592	2236	An issue was reported where a staff member with more than one employment record (a rehire, for example) was listed twice in the Episodes Staff drop-down list, and many of the Form DesignEHR form staff drop-downs. The drop-down lists are now validated, and staff no longer appear multiple times.
EV-1470		An issue was addressed where Creating a Recurring Group Event could sometimes include invalid participants. Now when a recurring Event is created or edited for any interval, the start and end dates of the Group Participants are respected.
EV-1481		An issue was addressed where Credentials that did not have a description entered in Configuration > Setup > Defined Lists displayed like LCSW – Undefined on the Rates screen in Configuration > Services/Payers > Service Definitions or Payers. The label on the Rates screen was updated and now only displays the Credential when there is no description.
EV-1608	4912	An issue was reported where adding a new column in Configuration > Services Payers > Sliding Fees unlocked previously locked cells and resulted in the cursor moving rapidly between cells. The error has been resolved, the default number of columns is now set to 10, and additional columns can be added without incident if needed.
EV-1749	5853	An issue was reported where the Search For Next Available could not produce results without at least one Staff filter criteria entered. The cause was due to the addition of ancillary staff, which essentially doubled the query. Updates were made so that the SFNA uses staffids to avoid duplication since Event or Service Staff can also be Ancillary Staff.
EV-1771		When applying an Overpayment type of Unapplied Payment, the transaction date assigned to the resulting Charge Increasing Credit was the date that the overpayment was applied, not the transaction date of the payment that generated the overpayment. This behavior was corrected, and now the Apply Unapplied Payment job for an overpayment uses the transaction date of the most recent remittance that created the unapplied payment.
EV-1825	5342	An issue was reported where users could not open the (FDNext) New Allergies form from a Progress Note on the Services screen. The issue was resolved by updating the form parameters to correctly return the Client id, allowing the form to open.