Detailed Findings

Scheduling Restrictions in the Provider Table

Revenue Cycle Transformation

This would be an enhancement that would allow the scheduler restrictions to be put in place specific to the filtered entries within the provider table.

Reports in Raintree - Report Scheduler

Revenue Cycle Transformation

This was discussed further in the calls with BI dashboards and tools as these export data and show similar data, but the filtering in some cases is different than what had been used historically. To allow reports within Raintree to run with the same historical filters and to allow enough time for them to successfully finalize, we would suggest to run these based on the report scheduler to allow them to run with an automated process that can kick off behind the scenes and run during off hours. The resulting report can then be sent to a task or email to be waiting for the applicable user to review the subsequent business day.

Refunds

Revenue Cycle Transformation

The recommendations here approach the topic from two points of view: Retroactive Refunds: to ensure an easy process with the Refunds that need to be issued. With refunds there are a few standard tools that can be employed to aid efficiency of the processing of refunds: Find potential refunds - https://kb.raintreeinc.com/help-10-2-500=find-potential-refunds-utility and Import issued refunds- to in bulk post those so that these are not an item a user would need to enter. - https://kb.raintreeinc.com/help-10-2-500=import-issued-refunds-screen Review and processing using Rev-Edition Follow up Dashboard for visibility into the processing - https://kb.raintreeinc.com/help-10-2-500=work-with-refunds-in-rev-edition Proactive: to help ensure that at time of service the amount collected is as close to accurate as possible. This is where tools and options within the Patient Payment Agreement and Counseling Form (PPAC) can be used and templates to aid in their setup defined to model specific common scenarios. For example, setting models for when there is a high deductible plan and payment condition would indicate to only use the required payment while deductible not met, or for patients where insurance coverage may be inconsistent to only use when no insurance coverage.

OTC Collections

Revenue Cycle Transformation

For this I would suggest a follow up working session on PPAC templates to setup a few samples, which can be set to use the payment terms only while the deductible is not met, or to estimate when then deductible will be met, to more closely align with what the patient owes after insurance adjudication. As noted with the section on refunds these common use cases for a PPAC can be set as a templated model for the teams to work from. Another feedback mechanism that is helpful to use as an indication that amounts to collect should be updated are decreasing copay follow up notes within the Follow Up Dashboard. Sorting by this follow up code and then by reason codes can help to give an indication when deductible and/or out of pocket maximums have been met and time of visit collections are no longer needed. An additional avenue to consider is that PPAC’s can be sent to patients for signature via the patient portal prior to the first visit. If the patient has the opportunity to review the details in a more focused environment if they do have an HSA that will issue payments to cover their responsibility amount this can provide them more time to share this feedback with the team to ensure that the front desk team does not collect in scenarios where the patient would have payments sent from the HSA with the payor directly following payor adjudication.

BILLING REPORTING

Revenue Cycle Transformation

The time here is also discussed with BI reporting. Some of these can be set to run on report scheduler to run during off hours. The report scheduler tool can run reports that are consistently reviewed on a defined scheduled date. This can be used to ensure that the same report is run with consistent filtering from one run to the next so that metrics can be true comparisons. As the time for these runs can be defined by the user these can be set to run during off hours so that system performance will not be impacted and run time does not leave a user waiting. For reports where different iterations and drill downs would want to be review, these can be found in BI and these drill downs and components within the reports will be items that are accessible without having to completely re-run the report.

Location History

Revenue Cycle Transformation

As this is consistent with the historical entries in their location table, continuing to use this method will maintain consistency and not need to update form script setup options. If this becomes difficult to manage we do have an option that would require a change to form scripts to use a fall back sequence from provider table to location table and could use a "default" provider with filtered entries to accomplish the accurate name with the applicable time frame for locations.

Automated Follow Up Actions

Revenue Cycle Transformation

There is an attachment below that shows the process in a detailed recording: https://drive.google.com/file/d/1GfMiEsw7YKsc8hw2IAlipBfzMBlj6Hhr/view?usp=drive_link The suggestion would be to begin with some of the straightforward follow up actions like a sending of medical records and identify when the team is taking this action consistently - Which payors is that done for? What ANSI reason code does that payor process with? Once these questions are clearly known a routing rule can be defined to take action automatically on behalf of the team. Below in the workflow to define the rules section, we will see an example for an insurance of Aetna and reason code 252 defined to run an automatic action of “medical records sending”.

"Not Touched" as a dropdown filtering options on Follow Up Dashboard

Revenue Cycle Transformation

Reviewed definitions during call. Not touched - a real person user has not needed to complete a follow up action on this claim

Vendor for Insurance Coverage Detection

Revenue Cycle Transformation

With Waystar the prerequisites were that they were already using the eligibility results being retrieved from Waystar and that contracting with Waystar as the clearinghouse was updated to include coverage detection. As the offering would become expanded to Availity and beta groups are reviewed the PRN team should be considered as a group to work with the beta offering.

Under Payment Detection

Revenue Cycle Transformation

This can be defined differently for payors that reimburse based on a fee for service model or a flat fee per visit. Below will be a link to slides from prior TherapyCon sessions that demonstrate not only how to define these behind specific payors but also how to run reporting to help in ensuring the targets defined are in line with actual reimbursements received. Link: Underpayment Detection - Slides TherapyCon 2025.pdf

TVBEN Completion Restrictions

Revenue Cycle Transformation

Capitation Payors

Revenue Cycle Transformation

Ledger Verifier

Revenue Cycle Transformation

Fee Schedule

Revenue Cycle Transformation