The Repricing Process at FinThrive

Before an account is repriced at FinThrive, it goes through a process called “charge compiling,” in which all claims for an account are compiled into one visit for which the claims have the same patient number and admit date. The charge compiling process works as follows:

1. The FinThrive system treats claims for an account in terms of a patient visit. The patient visit has either a single claim (bill type 111 or 131), or multiple interim claims (bill type xx2, xx3 or xx4), late charges (bill type xx5) or changes to the account (bill type xx6, xx7, or xx8).
2. When a claim is imported, the system checks for duplicates based on the following information: Patient Number, Bill Type, Admit Date, Service From Date and Service Through Date. If an existing claim in the database has the same values in all of these fields, then it is marked as “duplicate” before the new claim is added to the database.
   • If there is a single claim, then that claim is repriced. If there are multiple claims that have the same patient number and admit date, then the following process occurs.
     •  Claims are ordered by their submit dates (field locator 86 on the UB92). Claims marked “duplicate” are ignored.
     •  On interim claims (bill types xx2, xx3 and xx4), the system checks for duplicate condition codes, value codes, and occurrence codes and combines them, but all procedure codes and revenue codes on the claims are kept rather than combined.
     •  Late charge claims (bill type xx5) are combined with previous claims. This is the default processing with most customers. (There is an option, which is specified in a repricing job document, to treat an xx5 claim as an xx1 claim if the total charges on the xx5 claim are greater than the current total charge amount).
   • If there is an admit-to-discharge claim (bill type xx1), all previous claim information is discarded and only the information from the admit-to-discharge claim is repriced. This is also true when multiple admit-to-discharge claims are present.
   • Some customers require FinThrive to treat replacement claims (bill type xx7) as admit-to-discharge claims.
   • Some customers require the 117 claim to replace the corresponding interim series claim and takes part in the charge compilation when a xx7 claim exactly matches a specific interim series claim on admit and service dates.
3. Once the charge compile is complete, the compiled claims represent a billing “episode,” which is then used to reprice the account.
4. In certain instances, no claims for the account are processed due to missing or incorrect information. (These accounts appear on the Daily Manual Work report, which is sent to customers daily). For example, no claims for the account are processed if:
   • There is no initial interim or admit-to-discharge claim, but there is a claim with a late charge (bill type 115) or continuing interim bill (bill type 113). There is incomplete data available to reprice the claim because other related claims (bill types 111 or 112) are not present.
   • If the admit date or service-from date is after the Service Through Date. Then, the system is unable to calculate a correct length of stay for the account.
   • There is a missing payor code on the claim. If the Payor Code field is blank, then the system is unable to determine what contract terms to use to reprice the claim.
5. For the compiled claims, the appropriate terms for repricing are determined in the system as follows:
   • The payor code on the claim determines which contract to assign to the billing episode. If the payor code cannot be found, then the episode cannot be repriced.
   • Once the payor code is found, the correct Terms and Conditions (TAC) document and contract effective date is determined. The admit date on the episode is compared to the effective date of the TAC document, which determines which rates to use to reprice the claim. If no effective terms are found, then the episode cannot be repriced. In addition, the status for the effective contract must be “In Production.” If, for example, the status for the effective contract is “In Audit,” then the episode cannot be repriced.
   • For accounts that have been previously repriced, there are situations in which the previous reprice data must be reversed. This is always triggered by a change in payor code for the account:
     • If the new payor code does not match any contract effective date in the system, then previous reprice data is reversed, and no new reprice data is generated.
     •  If the new payor code is successfully matched to a contract effective date, then any previous reprice data is reversed, and new reprice data is generated for the newly matched contract.
6. Claims that are successfully charge compiled, plan-matched and possibly have reversed billing episodes, are repriced according to the contract in effect. Generally, this results in new repricing information in the form of an “invoice” generated by the system. Note that an account can have multiple invoices over time, as new claims are dropped and as reversals are generated.
7. There are episodes for which an invoice is not generated, although an episode correctly matches a contract effective date.
   • If the TAC document contains a stop calculation node, this indicates that a manual entry or review is required to correctly determine the reprice amount. For example, a pass-through calculation requires the actual cost or a complex stop-loss calculation requires a manual review.
   • The episode might not match any reimbursement service type definitions in the TAC document. This is an indication that the TAC document in the system is incomplete or contains incorrect service type definitions.
8. Once repricing is complete, then the incremental write-down amounts for all invoices generated (including reversals) in the production run are placed in the AR feed files for upload to the facility’s host system.
9. AR feed records are not sent under the following circumstances:
   • Either the earliest submit date (field locator 86 on the UB92) on the episode or the Service Through Date is prior to the production date of the effective contract used to reprice the episode. (The AR feed records are not sent because the facility has already processed and discounted those earlier claims in their system.)
   • The new incremental write-down would place the account in a credit status. The credit status is determined by adding the Expected Payment + Total Actual Discount + New Write-Down Amount. If the total of these three amounts is greater than the Billed Charges on the episode, then the write-down is not sent.
   • The older invoices being reversed were not originally sent (because they occurred prior to production).