Electronic MSP Claim Balancing (Q&As)
Effective July 3, 2006, Electronic Medicare Secondary Payer (MSP) claims are required to have CAS segments and balance. MSP claims will be rejected if the paid amounts and the adjusted amounts by the primary payer do not equal the billed amounts or if the claim lacks standard claim adjustment reason codes to identify adjustments.
Here are some FAQs regarding electronic MSP claim balancing requirements.
Must the service line level billed amount, adjustment amounts, and paid amount balance?
No. A significant number of non-Medicare payers currently report adjustments that apply to all services contained in a claim at the claim level in a paper remittance notice, and report adjustments that apply only to specific services at the service line level. Since the claim level adjustments also apply to the services, it would be necessary to apportion those claim level adjustments among the services to allow the service line to balance in those instances. As result, CMS will not require balancing at that low of a level, nor require that providers apportion claim level adjustments made by a primary payer.
How should a shared system determine whether a primary payer's claim information balances in a Medicare Secondary Payer (MSP) claim?
An X12 837 MSP claim is supposed to represent a combination of claim data and remittance data. As result, the 835 balancing rules can also be used to balance primary payer billed, adjusted and paid amounts in an 837 MSP claim. Translated from the 835 segments and loops to the corresponding 837 segments and loops, the formula to be used to determine whether primary payer claim data balances is:
The total billed amount (CLM02) minus the total of all CAS adjustment amounts ([Loop 2320 CAS03+CAS06+CAS09+CAS12+CAS15+CAS18] + [Loop 2430 CAS03+CAS06+CAS09+CAS12+CAS15+CAS18]) must equal AMT02 in the COB Payer Paid Amount segment in Loop 2320. If it does not equal that AMT02 COB Payer Paid Amount, either some primary payer information is missing or was reported incorrect in the MSP claim.
If the total billed to the primary payer less the total of all adjustments made by that primary payer does not equal the total paid by the primary payer, the primary payer data does not balance and that claim must be rejected for resubmission when corrected.
How should I balance the primary payer information when there is more than one primary payer?
As indicated in §90.2 of Chapter 24 of the Medicare Claims Processing Manual (Pub. 100-04), it is not possible to submit a HIPAA-compliant electronic claim to Medicare when there is more than one payer that is primary. The X12N 837version 5010A1 does not permit reporting of allowed amount for more than one primary payer. As result, these claims are to be submitted on paper with the Explanation of Benefits issued by each of the primary payers. Since claims submitted on paper are still sent to COB trading partners as X12N 837 version 5010A1 transactions, however, when manually entering the paper primary and MSP claim data, a contractor must still make sure that the amount paid by the primary payers is equal to the amount billed to each of those primary payers less the amount of the adjustments made by those payers. If that data does not balance when Medicare transmits to a COB trading partner, that trading partner could reject the claim and neither the COBC nor the contractor that processed the MSP claim would be able to correct the primary payer data to allow the claim to fully balance. As result, even paper MSP claims need to be rejected if the primary payer information does not balance.
What should I do if a tertiary payer that is a COB trading partner refuses to accept the COB claim because the service level billed, adjusted and paid amounts from a primary payer do not balance?
Point out that the 837 implementation guides do not require that the service line data from a primary payer balance. As result of industry variations in reporting of adjustments at the claim and service levels, it is not always possible to balance at that level.
The balancing edit could result in the rejection of many MSP claims. Can I apply the edit on an informational basis for one month, and postpone actual rejection of claims that contain out-of-balance primary payment information until the following month? Since I cannot apply this edit on an informational basis until the shared system release is issued, this means that I would apply the edit on an informational basis in July and begin rejection of claims for this reason in August. When I apply an edit on an informational basis, each provider that would have had that claim reject if submitted in July will be notified of that fact. This will help to reinforce the educational information we issue about this new edit and let the providers know of the personal impact of the edit on their claims.
Yes, that would be acceptable, and even preferable, if you have the ability to apply this first on an informational basis.
Why is CMS requiring that primary payer data balance on claims now? We never had to do this before and the 837 implementation guides do not actually say that primary payer information must balance.
Although the 837 implementation guides do not specifically require this, it is reasonable to expect that the information supplied on an MSP or a COB claim be complete and accurate. Although the primary payer information is used on only a limited basis by Medicare, some COB trading partners make more extensive use of that data. A number of trading partners have refused to accept COB claims from the COBC if primary payer information does not balance at the claim level (loop 2320), reasoning that if that information does not balance, it must be incorrect or incomplete. Since only the submitter of the MSP claim can correct that information, it is important that these claims be rejected by Medicare for correction by those submitters to enable those claims to be accepted by tertiary payers.
A complete list of current 5010A1 pre-pass edits is available in the WPS Bulletin Board in the EDI file library in the HIPAA directory (file name: 5010A1.doc).