EDI Claim Manager (EDICM) is the core module of MSA's EDI solution that improves the entire billing and collections process from claim submission to workflow management. EDI Claim Manager loads your claims, automatically checks them for errors, and shows which claims are valid and which need to be corrected. Users can easily create, correct and track claims while reducing rejections. Users can also manage the revenue cycle for every claim, including secondary claims and Workers' Compensation claims.
EDI Claim Manager works with almost ALL software that produces claim files!
We will support claims with DOS on/after October 1st using several methods in our payer settings:
In particular, Workers Compensation and Auto Medical payers will default to the Pass-through Method as there is still great uncertainty about these insurance plans affected by legislation in 50 states.
Whatever happens on October 1st, MSA will be monitoring electronic transactions closely and making adjustments as we go forward. While we cannot automatically convert diagnosis codes, our goal is to maximize the acceptance rate of your claims in a changing environment.
Here are ten facts to consider in advance of October 1, 2015, when ICD-10 is set to become the required diagnosis code structure for medical claims.
• Send claims to payers electronically.
• Over 98.5% first-pass clean claim rate.
• Get real-time claim status instantly.
• Correct invalid claims online in real-time.
• Click on a claim to see: complete history, current status (valid or invalid) and all payer responses.
• Secondary Claims - Easily create and edit, and identify with ease when claims are invalid.
• Challenge underpayments successfully before it is too late.
• Prove claims were filed on time with a "Timely Filing letter".
• File Workers' Compensation claims electronically and include supporting documents.
• Access all claims data from a single screen to check status, make corrections and resubmit claims.
• Claim Manager can integrate with your Practice Management system.
• Claims that are not in a paid status and are over a certain number of days.
• Claims that are Invalid only for Clinical Claim Scrubbing Errors.
• Eligibility Requests that are Invalid because of missing information or are Rejected by the Insurance Payor.
• Denied ERA transactions that are denied with a specific Claim Adjustment Group or Reason Code.
• Provides a detailed view of all ERA Transactions in an ERA file. Detailed view includes: charge amount, amount paid, allowed amount, Claim Adjustment Group and Reason codes.
• Provides users with the ability to sort ERA transactions by CPT code, check number, Payer, Claims Adjustment Group and Claim Adjustment Reason Code, and Status.
• Allows users to view ERA transactions by status, including Denied ERA Transactions.
• The Denial Screen allows users to add notes while working denials that will be attached to the ERA transaction. Users can also add a follow-up status to the ERA transaction such as Paid, Appealed, etc.
• Analysis reports provide data such as a breakdown of CPT codes that were denied for Claim Adjustment Group Codes and Reason Codes.
• All ERA data is stored in the Expects Table. The table stores the CPT code with modifier, charge amount, allowed amount and expected paid amount. Users can refer to this table to see if they are over/under billing an insurance company and compare allowed amounts.
No more manual posting of paper EOBs and patient payments.
• Lockbox ERAs - pulls all 835s generated.
• Original Images - auto-converts all original EOB images received into 835s.
• Deposit Reports - generates a report with all deposits processed.
• Non-Financial Images/Correspondence - puts all original documentation classified as non-financial into easily referenced images.
• Incomplete 835s - pulls all reports listing 835s containing incomplete information.
• Exception Reports - pulls all reports listing all financial data that could not be converted to an 835 due to an exception of missing information.
• Exception Images - pulls all original images listed as exceptions, because an 835 could not be generated based on the information found on the image.