Detailed Findings

Updating Payors

Revenue Cycle Transformation

There are really 2 avenues for improvement here that may help. With the first having a simplified workflow for the teams to follow, the SBP coverage correction tool option helps to enforce that the coverage correction process must be followed by users upon saving a change to the payors. This also provides the benefit of an updated workflow that does not have the user have to later go back and add the details for the parent or spouse if the policy is from a different member of the family. The second area of consideration is the ledger verifier that can help to surface when there are potential issues and help to resolve them early. The ledger verifier can be set to run automated solvers when there is a proposed solution from Raintree. This can also be run as a scheduled report that can help to highlight if and when there are common mistakes that can be used for internal training.

Form Script - SCHIN Flexibility in Column Configuration

Revenue Cycle Transformation

This would be a custom option to add additional columns to be able to configure within the form scripts specific to each payor what they would like to see included in the output. (Or added as a suggestion for future standard enhancement)

Payor - Restriction on the BC selection option based on the comments section within that payor

Revenue Cycle Transformation

This would be an option to limit payors like the <BC:P> comment that would only allow a payor to be selected as a P, but instead would be something like does not equal a P. Currently this would be a custom request or a suggestion for a future enhancement.

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.

Ledger Lock

Revenue Cycle Transformation

Ledger Lock is recommended for use. Challenges that were discussed: For items that do need re-allocation best practice to maintain ledger lock integrity is to maintain the lock and not bypass it. The payment would still be re-posted, however the original incorrectly applied payment would be reversed and the correction would be posted all with a posting date of today (current day). In this way, the history is maintained and the historical stats remain consistent. The current day is a wash for overall cash receipts as there is a reversal and the reposting that correspond with one another. The correction will appear as a correction off of one location and onto another with the current day/month for the correction to reflect in financials.

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”.

Follow Up Cues to Include Balance without Duplicates

Revenue Cycle Transformation

This is an option that can be enabled by the Raintree team within the global.ini. To accomplish this a case will be the best method here as it is added into the global.ini during off hours and we will want to coordinate date and time to conduct this during off hours.

"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