Posting an ANSI 835 Remittance



ANSI 835 Remittance - Three Steps to processing 835 files

Set-up, Test, Implement

Lisa Stavig

CUG 2007

Setting-up

The following Reference File records need to be set-up before posting:

Clearinghouse record

Payor records

Claim Adjustment Group Codes (These will be automatically created during the MB 2007 update process)

Claim Adjustment Reason Codes (These will be automatically created during the MB 2007 update process)

Remark Code Records

Adjustment Reason Codes

Clearinghouse Record

• A Clearinghouse record is needed to tell the program where to find the remittance files. Before creating this record decide where you want to store your electronic files. One suggestion would be to create an ANSI835 folder and within that have sub-folders for specific payors and/or for files to post and files posted.

[pic]

• Once a location has been determined for storing the file, proceed to creating the Clearinghouse Record located in the Medical Reference Files. The claim form name will be ANSI835. If multiple providers exist on the user’s system, any of the provider numbers can be used. The other field that needs to be filled in on this screen is the Remittance Path (again, this points to the location from which remittance files will be uploaded.) This path needs to end with a backslash ‘\’. (e.g., S:\Program files\Solomon\Medtrac\ANSI835\).

[pic]

Payor Records

The next step will be to update CPID and INKEY fields on the Payor records.

All clearinghouses should have a list of payor ID codes to refer to for updating the CPID codes. As explained below the CPID will allow the system to identify the payor returning the payments. The INKEY will identify what payor the secondary claim has been forwarded on to.

[pic]

• Payor records are needed to tell the program how to identify the payor returning the payments. At the time of processing the 835 the user can choose to enter a CPID code for identification purposes or they can specify what payor the payments are from. The program determines a match based on CPID code (or payor number if this option is chosen) and other factors like policy numbers in the patient-payor records.

• A listing of the INKEYs may be harder to come by then the CPID list. Most Medicare carriers publish a directory of Medigap insurers but I was unable to locate a directory for auto-crossover insurers. One way to locate the number for auto-crossover insurers is to look at the 835 file before it is posted and copy it from there. You will find it in the NM1 TT segment, element 9.

CLP*00835820289678*19*83*11.93**MB*1107171089010

NM1*QC*1*DOE*JOHN*O***HN*51111111A

NM1*74*1

NM1*82*1******UP*D83298

NM1*TT*2*OLYMPIC HEALTH MANAGEMENT SYSTEM*****PI*30163

See Note at bottom of hand-out regarding CMS’s re-assignment of N-Key identifiers.

The Adjustment Type is historically what users have used to identify/categorize the various adjustments that are performed on a service. Additional Code types have been added to the system which are issued from the ANSI standard. The additional codes have no effect on line item transactions or on balancing. Looking at a paper copy of a Medicare remit, it has the “Group”, “Reason”, “MOA” and “Remark and Reason” codes. These same codes appear in an 835 file.

The Adjustment and Remark Codes

Claim Adjustment Group Codes: (Source: ANSI standard) Codes identifying the general category of payment adjustment. Currently these are:

• CO - Contractual Obligations

• CR - Correction and Reversals (removed in new version of ANSI835)

• OA - Other adjustments

• PI - Payor Initiated Reductions

• PR - Patient Responsibility

These will be automatically created during the MB 2007 update process.

[pic]

Claim Adjustment Reason Codes: (Source: custom_html/claimadjustment.htm) Code identifying the detailed reason the adjustment was made.

These will be automatically created during the MB 2007 update process.

[pic]

Remark Code Records

The Remark Codes also need to be updated. These are not automatically updated with the MB 2007 version because this table was also used for prior remark codes for the previous remittance process. It is available as an optional update, however. Remark Codes have a big impact on the remittance process since they can determine if an adjustment is performed on a service or not. Cortex has maintained some flexibility in this area so customers can suit the system to their needs.

[pic]

The Zero Payment Code prompt in the image above has three options which take effect under the following conditions:

• The service in question has a 0 allowed and paid amount.

• This remark code appears on the Claim MOA or service LQ segments.

• Of all the codes found for the specific service, the one with the highest priority determines the final action.

Adjustment Reason Codes: are needed to tell the program what adjustment type codes to apply to a service adjustment. The system takes in the Claim Adjustment Group Codes and Claim Adjustment Reason Codes from the remittance file and locates the associated (site-specific) Adjustment Type. It is possible that Cortex will use Adjustment Type Code “001” as the default.

[pic]

Test

Important Note from Cortex: We insist that customers just starting to post 835 do so against a test database until they are confident that as much data as possible is being posted and that it is posting correctly. When a test DB is used, it needs to be created from the customer’s live database(s), so remittance data matches recently-submitted claim data. In light of this, if remittance posting spans multiple claim-submission periods, the test database may need to be created multiple times from the then-current live database(s). As a result, it is recommended that the user either set up the reference files directly in their live DB (after making a backup of the live DB), and keep those reference files in-sync with the test DB or keep detailed notes about setting up their reference file data, so it can be done quickly with each new iteration of the test database.

The customer must be posting the file to the same database from which they billed the claims (as the remittance data gets matched to the original services billed during the posting process). Therefore, the customer must separate the received remittance files by applicable database and only upload those related to the currently-active database at the time that it’s active.

Users who will be running the tests should be careful to check, for each test posting, that they are logged into the test database and not the live database.

Implement

To post remittance files once the system has been set-up to accept them, open the 835 Remittance-Posting screen located in the Outpatient Insurance Billing menu and select desired criteria.

[pic]

• “Use Name-Matching to Verify Patient Accounts”: If this is checked, the remittance program will only post to the given patient account if the patient name in the remittance file matches the patient name on the patient demographics record (as a partial name match). Some customers prefer to uncheck this box to allow for posting in the event of legitimate patient name changes. The name-matching feature is most useful for customers with multiple databases in which it’s possible (but very unlikely) that a payment would be posted to the wrong account in the wrong DB because it had the same relevant attributes as the correct account in the correct DB.

• “Cash Receipt Batch Number for all Payments in File(s)”: The user-specified cash receipt batch number used by the customer site to track all payments associated with a particular batch. This data has the same function as it does when posting payments manually.

• “Deposit”: The deposit number to be used on the Cash Receipt.

• Use Data matched versus specified Payor: By matching elements like patient-payor policy number and payor CPID code, it is possible the program can determine automatically the appropriate payor under which to post the payments. However the entity generating the 835 file often doesn’t provide data complete enough to use this data-determined feature, in which case users can explicitly specify the payor associated with the payments in the file (assuming that there is only one for a given remittance file) by using the “specified payor” option.

• Crossover Payor Options:

i. “Service Status to use if no secondary payor found”: This is the status the service will be set to in the following situation:

1. The service has a remaining balance.

2. The claim is remitted with a status of 19 (Processed as Primary, Forwarded to Additional Payer (s)).

3. No Payor was found with a matching InKey (note: the InKey to match comes from the NM1 (TT) record for “Crossover Carrier”).

ii. “Service Status to use if no related secondary payor found”: This is the status the service will be set to in the following situation:

1. The service has a remaining balance.

2. The claim is remitted with a status of 19 which means Processed as Primary, Forwarded to Additional Payer (note: the status comes from the CLP segment).

3. A Payor with a matching InKey was found, but the payor number did not match.

• “File Options”: This is simply a utility to aid the system in reading text files from disparate sources. For instance, Zirmed remit files usually have a “~” symbol at the end of each line. Putting that tilde in the box tells the system to convert them into line feeds.

• “Test Mode (system use)”: If checked, the system will process the file except nothing is written to the database. It will also cause an extensive description of what would have been written to appear in the event log. This is really for power users, as all the data is in the event log and will not appear in the Patient Account Details or similar screens.

• Minimum Logging: Indicates less information should be written to the log file. Customers should experiment with this option to see which they prefer.

NOTE: Only the remittance file you wish to work with should be in your remittance folder (based on the clearinghouse as noted above). The program will process all files in the folder and all will receive the same batch number.

Once the desired criteria have been selected complete each of the three steps listed below. It can not be stressed enough how important it is to review the event log after each 835 file has been posted. The content in the event log is the key to successful claim management.

1. Press the “Begin Processing Button” to upload any/all remittance files waiting to be uploaded from the remittance directory. These get processed serially from the remittance directory.

1. Review the event log to find data that couldn’t be posted automatically or errors and warning messages and make the necessary adjustments to the data set-up to insure that similar payment will be posted should they appear in the future. Payments/adjustments that couldn’t be posted automatically must be handled manually. Important: identical files cannot be run multiple times without restoring the database, as that will result in duplicate transactions being posted. Clearing the data from a partially-posted file is not a trivial thing to do, therefore, re-posting files is not recommended in most cases.

2. Balance the posted data (payments and adjustments) against a paper EOB and the check amount or EFT amount and against the Cash Receipts report, as done with a manually-posted batch.

Common problems and troubleshooting suggestions:

(1) Problem: The file is verified as being structurally sound, per the event log, but doesn’t post payments.

Possible Solution: The file may be marked as a test file (via a “T” in ISA-16); we’re finding that even with live data files the carriers sometimes forget to flip this flag to a “P” for production, though the files are production files, so users are having to do that manually now until their carriers can rectify that. A message will appear in the log file.

2) Problem: Nothing posts because there is no remittance path set in the clearinghouse records. Therefore, the program can’t find the remittance files.

Solution: Enter the applicable remittance path(s) on the 835 clearinghouse record.

**Note** According to CMS release CR5662, The Centers for Medicare & Medicaid Services (CMS) has decided that, effective October 1, 2007, all mandatory Medigap (“claim-based”) crossovers will now be accomplished through its Coordination of Benefits Contractor (COBC). Starting with June 2007, CMS’ COBC will gradually begin to assign new Medigap claim-based COBA identifiers (range 55000 to 59999) to Medigap insurers that have not voluntarily moved to the COBA eligibility file-based crossover process. CMS anticipates that the COBC will complete the execution of crossover agreements with Medigap claim-based insurers and assign new COBA Medigap claim-based identifiers to these entities by August 31, 2007. As the COBC assigns a new COBA Medigap claim-based ID to a Medigap claim-based crossover recipient, CMS will alert all Part B contractors, including MACs, and DMACs via e-mail of this action on a weekly basis. The CMS alert will include the following information: affected entity’s name; the entity’s multiple formerly contractor-assigned Other Carrier Name and Address (OCNA) or N-key identifiers; and its newly assigned COBA Medigap claim-based ID. Upon receipt of the CMS alert, the affected contractors shall manually add the newly assigned COBA Medigap claim-based ID to their existing insurer screens or tables to replace the formerly assigned OCNA or N-key identifier. Contractors shall also maintain a link to the COB website () for purposes of receiving updates to the COBA Medigap claim-based ID listing.

The affected contractors shall post CMS’ Medigap claim-based crossover transition announcement in its entirety on their websites that are accessed by the public and insurers. These contractors shall also mail the CMS announcement on a one-time basis to their electronic Medigap claim-based crossover recipients and shall also notify their paper claim recipients through information included with their next scheduled claim mailings. Providers should note the following: Effective October 1, 2007, the COBC will assume responsibility for the Medigap claim-based crossover, which is driven by information that participating providers enter on the incoming claim. The primary change for providers resulting from this transition will be that they will need to include a new Medigap identifier, even in advance of October 1, 2007, on their incoming Medicare claims to trigger crossovers to Medigap insurers. During June through August 2007, CMS will assign each Medigap insurer that does not provide an eligibility file to the COBC to identify all of its covered policy or certificate holders for crossover purposes a new 5-digit COBA Medigap claim-based identifier (ID). Providers may reference a weekly updated listing of the newly assigned COBA Medigap claim-based IDs for Medicare billing purposes at the following website: Claim-based COBA IDs for Billing Purpose.pdf. Once the COBC has assigned a new COBA Medigap claim-based ID to a Medigap insurer, participating providers that wish to trigger crossovers to Medigap insurers will be required to include that new identifier, as found on the CMS COB website, on their incoming Medicare claims. Failure to do so will result in their claims not being successfully crossed over to the Medigap insurer. If the older contractor-assigned number is included on the claim, Medicare will include the standard MA19 message—‘Information was not sent to the Medigap insurer due to incorrect/invalid information you submitted concerning the insurer. Please verify your information and submit your secondary claim directly to that insurer.’—on the provider’s electronic remittance advice (ERA) or other production remittance advice for the associated claim(s).

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download