Quantcast
Channel: MediTouch Support » Tutorials
Viewing all articles
Browse latest Browse all 138

New Accounts Receivable Workflow

$
0
0

We recently implemented accounts receivable (AR) enhancements to the billing and reporting modules of the MediTouch Practice Management system. These enhancements are based on years of user feedback. The goal of these improvements is to provide you with balanced and reportable AR totals that will feed data to our new Business Intelligence (BI) Reporting tool that will be launched later this year.

During the transition, new workflows must be adopted. The suggested changes featured in this help page will contribute to workflow efficiency and enable historical data to conform to the new AR enhancements.

To begin, we ask that you review the Accounts Receivable Enhancements help page mentioned in the July 30, 2015 Release Notes. Some of the important topics from Accounts Receivable Enhancements help page are referenced here.

We appreciate all of the great requests and feedback from our clients. All requests should be submitted using the MediTouch Feature Requests link.

Key terminology used in this help page:

  • Adjudication: The history of applied payments and adjustments for a service line or claim.
  • Charge: The complete set of service lines attributed to a patient encounter.
  • Claim: A set of service lines billed and submitted to a payer.

AR Ledgers and Balancing

Expanding on the structure of the MediTouch AR Ledger, it is important to understand charge versus claim adjudication.

  • Charge adjudication is the end result of one or more claims.
  • To uphold our exceptional clearinghouse structure, ERAs/payments are applied to claims.
  • Based on the information applied to the claim, values are established in the ledger and the charge is properly balanced.
  • The following sections describe the areas that currently display charge-based versus claim-based balancing. This knowledge will help prevent confusion caused by unexpected balancing behavior.

Claims-Based Adjudication

Claim Details

arClaimDetails
  • The Claim Details view displays adjudication information that was applied to the individual claim.
  • This is not necessarily an accurate view of the charge because more than one claim could be involved in the billing of the charge (e.g., resubmitted claims, secondary claims).
  • If there is a single claim billed for the charge, the claim and charge adjudication would be identical.

Charge-Based Adjudication

Apply Payment Screen

applyPayment_charge
  • The summary information above the service line details is charge-based.
negInsBal
  • The insurance balance in service lines is charge-based.
  • When applying a payment, if the service line has too much adjudication information (i.e., insurance balance is negative) the service line turns red.

We will make our best effort to automatically balance the charge based on the historical data that we have, but, at times, you must manually balance the charge to $0.00.

Resubmission Adjustments Widget

arResubmission
  • When resubmitting a claim, you have the option to manually update prior adjustments. The information provided is charge-based.

AR Ledger

newAR_arLedger
  • Ledger totals are charge-based.

Workflow Suggestions

The following best practices will help eliminate unnecessary steps and ensure historical data will accurately conform to the AR enhancements.

Do Not Void Prior Claim Adjudication

Use the void functionality when a transaction has been erroneously created (e.g., void a payment that was entered by mistake). Voiding transactions to balance an account is discouraged and must be avoided whenever possible.

If the ledger is ever out of balance and your intention is to update the balance, a new adjudication transaction should be entered to reverse the information that is already present. In the past, these types of transactions were not possible since we forced you to balance to $0.00 any time adjudication information was applied.

Warning: If you attempt to void transactions on resubmitted claims and/or primary/secondary claim combinations originally applied before July 31, 2015, the ledger may not accurately update. However, void transactions that occurred after July 31, 2015 will not result in any balancing issues.

newAR_negTrans
  • Manually enter a negative transaction to the most recent claim rather than voiding (unapplying) the payment.

We understand that clients sometimes unapply a payment from a resubmitted claim and then reapply the payment to the new claim. Our efforts are to address the reasons why users currently perform this unnecessary step. We are already in the process of updating our secondary creation logic to always complete the required fields regardless of which claim the payment(s) are applied to. If there are other reasons why this action is being taken, we would like to hear from you. All requests should be submitted using the MediTouch Feature Requests link.

Balance to the Charge

When applying payments to claims, apply only the necessary adjudication information to balance the charge’s service line to $0.00.
newAR_balChg1
  • Example: A claim was resubmitted and the insurance adjustment and patient responsibility from 98941 was reversed.
newAR_balChg2
  • The adjustment and patient responsibility are now $0.00 and the insurance balance is $70.00.
newAR_balChg3
  • When applying payments to the new created claim, only $70.00 in adjudication information needs to be entered to balance the charge to $0.00 and finalize the claim.

When applying payments, the old system forced you to balance to $0.00. This restriction was removed based on years of client requests. The flexibility to apply partial transactions requires you to manually balance the charge.

Understand Reverse Adjustments

Insurance adjustments and patient responsibility will be reversed by default (on the Charge Entry page) when resubmitting a claim. This default selection matches the old AR logic.

newAR_reverse
  • In the old workflow, adjustments and patient responsibility were removed from the ledger. The new AR logic creates a new transaction to track the event.
newAR_reverse1
  • In this example, the claim was submitted and an ERA was auto-posted. The user identified an underpayment using the expected amount fee schedule underpayment report.
newAR_reverse2
  • During resubmission, the adjustments were reversed using the default option.

Know When to Reverse

  • If you reverse adjustments during resubmission and then void the original payment on the resubmitted claim, this results in negative adjustments on the charge. You must only perform one of these transactions.
  • If a correction and reversal ERA is received, the payer will reverse these transactions.
  • If the correction and reversal is fully posted, this may result in a ledger that is not balanced to $0.00. The new AR logic manually reverses adjustments, when possible, to help the charge’s insurance balance to $0.00 when these correction and reversals are posted.

Note: Applying payments to claims that were applied on or before July 31, 2015 is the most common way for automatic system balancing issues to occur, depending on the situation. The primary situations to be aware of are posting to resubmitted primary claims with payments and primary and secondary claims for the same charge. In these situations, we recommended you only apply the necessary positive and/or negative transactions to balance the charge to $0.00. Full postings may cause balancing issues that will need to be corrected manually.

Use the Delete Option to Remove Service Lines

newAR_delete
  • When resubmitting claims, use the Delete option to remove service lines that you do not intend to leave on the charge.

Post to Restored Secondary Claims

newAR_restored
  • In isolated cases, the restored charge data displays patient responsibility amounts that were originally transferred to the secondary insurance balance. When this occurs, you need to manually reverse the patient responsibility.

Reverse Historical Write-offs

newAR_oldWriteoff
  • In the old workflow, write-offs would be included in the Adjustment column in the ledger.
newAR_newWriteoff
  • Historical write-offs still display this way in the new workflow. When reversing a historical write-off, that service line may not correctly balance.
  • Applying a patient payment after performing a reverse write-off is causing Ledger Discrepancies. We are working to update this logic.
  • If any balancing issues occur, navigate to the Apply Payment screen and enter the necessary transactions to balance the service lines to $0.00.

Applied to Claims without Insurance Payment

newAR_appliedToClaims
  • This logic was updated for future occurrences only.
  • Historical data will not be updated as we are removing this section in the near future.
  • This section will be removed when logic is added to reduce the balance in the A/R Aging Days

Patient Aging

newAR_arAgingDays
  • This logic was updated for future occurrences only.
  • We are researching the possibility of a mass update for affected records.

Viewing all articles
Browse latest Browse all 138

Trending Articles