November 2008 Newsletter
Automatic Secondary Processing of Claims through Xpeditor
Reducing the amount of time billers spend submitting electronic secondary claims is an ongoing goal for Quadax. To achieve this goal, Xpeditor has the ability to create secondary claims and automatically populate secondary information on both the claim and the corresponding Coordination of Benefits (COB) screen. For those clients new to Xpeditor or those unfamiliar with all its capabilities, here is a brief explanation of how the Automatic Secondary Process (ASP) works along with the associated options located within Xpeditor’s Remittance Screen.
When Quadax picks up an electronic remit, i.e. (835), an Explanation of Benefits (EOB) is created for every claim returned in that 835. When this process is complete, the ASP process begins. The ASP Process has certain criteria “hard coded” into its logic that must be met for a secondary claim to generate. First, a primary claim must be located in History. Users have the ability to set the criteria that Xpeditor will use to identify the primary claim.
Once a primary claim is located, Xpeditor will determine if a secondary or tertiary payer is listed on that primary claim. If there is a secondary or tertiary payer listed, Xpeditor will check the associated 835 to see if any Patient Responsibility codes (PR1, PR2 or PR3) were returned. If all of the criteria above are met, an ASP Claim will be created.
Flexible Criteria for Claims
For greater flexibility, additional criteria can be used to prevent ASP claims from being created. For example, users have the option to stop ASP claims from being created for claims that were reported as electronically crossed-over by the primary payer. There is also an option to stop ASP creation when the primary payer denied the entire claim.
Once an ASP claim is created, Xpeditor has several options to help populate information on both UB and1500 claims and the corresponding COB screens. To establish COB Best Practice standards, Quadax contacted current payers in various states to confirm how they wanted secondary information sent to them. Based on those Best Practice Standards, all UB COB information is sent out on the outbound 837 at claim level. All 1500 COB information is sent out at both the claim and line level. It is important to keep in mind that electronic secondary billing is still in its infancy stage. Consequently, there is no one universally accepted standard for the ANSI implementation guide. For example each payer has its own implementation guide.
COB Data
Another important piece of the ASP creation puzzle is obtaining COB data from the 835. Xpeditor offers two helpful scraping options. First, the COB data can be scraped for UB and 1500 claims (both at the claim and line level). Second, a “Rollup” option is available for UB claims. If the “Rollup” process is turned on and a UB claim is returned at the line level, Xpeditor will add up all lines that contain the same ANSI Group and Reason Code and place this total at the claim level. After populating COB claim level information, Xpeditor will then remove all the line level information from the COB Screen.
The options to assist billers in auto-populating data on both the claim and the COB screens are located within the Payer Exclusion portion of the Remittance Settings Tab. First, ASP claims come into the Selector with a NAMI claim type. NAMI stands for National Miscellaneous. These Claim Types will need to be changed on all secondary claims that will be sent electronically. By choosing Set ASP Claim Type, Xpeditor will automatically assign the correct Claim Type to all payers that accept secondary claims electronically. As new payers start accepting secondary claims, those Claim Types will be changed accordingly.
Another option user’s have for UB COB claims is to populate Amount Qualifiers required by secondary payers automatically. For example, the B6 (Allowed Amount) will be populated for all payers, the T3 (Total Submitted Charges) will populate on Aetna, Medicare, and WV Blue Cross claims, and the A8 (Non-covered charges) or YT (denied charges) will be populated for United Healthcare if returned in the 835.
Hardcopy UB Claims
Provisions have also been made to populate information on UB secondary claims that are sent hardcopy as well as electronically. By choosing the “populate value codes to NAMI claims” option, Xpeditor will populate Value Codes A1, A2, A7 and the corresponding amounts in blocks 39-41 if they were returned in the 835. Due to restrictions from both CMS and NUBC, however, these Value Codes can only be present on hardcopy claims.
In addition, users also have the option to auto populate the Prior Payment (block 54A) and the Estimated Amount Due (block 55B). If the Claim Type is NAMI, (block 54A) will be calculated as: Payment + Contractual. If the secondary claim is a Non-NAMI Claim Type, (block 54A) will contain the actual payment and (block 55B) will automatically be calculated as: Deductible + Co-insurance + Copay. These amounts are scraped from the corresponding 835.
Before turning on these options to populate data on the secondary claim or the COB Screen, please make sure that all After ASP converts are removed. The ASP/COB process is a complex issue that Xpeditor simplifies greatly. However, if you have questions or concerns, please contact your Quadax Service Representative.