Overview of Electronic Secondary Claims (COB)

Electronic Secondary Claims (COB) Overview-NextGen® PM 

Overview of Electronic Secondary Claims (COB) 

General Information 

This guide is designed to assist users in the set up and process of creating HIPAA ASC X12N 837 

Electronic Secondary Claims (COB) when primary payments have been posted manually by utilizing the 

COB window in Payment Posting. 

Payments posted when the NextGen® system loads 835/ERA file transactions via the ERA Posting 

Process automatically imports information required for generating electronic secondary claims. This 

eliminates the need to utilize the COB window in Payment Posting. 

Once the original set up of the COB process is complete, there is minimal effort required to set up 

additional payers. 

Getting Started 

First, verify if your EDI trading partner accepts electronic secondary claims by reviewing their payer listing 

located on their website or contacting them directly. Since Medicare claims are no longer accepted on 

paper without a waiver on file, electronic Medicare secondary claims are typically available. Consult with 

the trading partner on the process for uploading these secondary electronic claim files from the 

NextGen® system to their system. 

To manage the secondary claim files, a naming convention and filing system for these files should be 

determined. For example, a directory could be created called: Claims Folder>Medicare>COB Files. It is 

important to place the directory for the downloaded files in a location that can be accessed by all the 

appropriate users who create and submit claim files. 

NEXTGEN® Healthcare, Inc. EPMClaims 

© Copyright 2010 All Rights Reserved Confidential and Proprietary DO NOT COPY 

V5.6SP1 Sept2010 Page 1 of 29


Electronic Secondary Claims (COB) Set-Up 

Libraries 

Libraries>Reason Codes 

Reason Code Libraries provide the ability to configure business rules which can be used to automate 

electronic transaction posting. 

The HIPAA X12 Standard Reason Codes Library (File Maintenance > Libraries > Reason Codes) is 

preloaded in the NextGen® application and contains industry Standard Reason Codes. Only HIPAA X12 

Standard Reason Codes are permitted for electronic secondary claims. 

Libraries> Reason Codes> Reason Code Priority 

Reason Code Priority has two main purposes: 

1. To determine the order reason codes will display in the transaction posting screen & COB window 

during payment posting 

2. To determine which business rules take priority when multiple reason codes are used on one line 

item. 

For example, if one code indicates a transaction status of “Appeal” and the other code allows the 

remaining balance to be moved to the next responsible payer, the system will process the reason codes 

according to which reason code appears first in the priority list. 

Select a Reason Code Library. Right-click and select Reason Code Priority. To move a code to the top 

or to the bottom of the list, highlight the code and select the blue “up” or “down” double-arrows. Use the 

blue “up” and “down” single-arrow to move a code ine by line. 





Best Practice: Move commonly used HIPAA reason codes to the top to easily select during manual 

payment posting. The four most commonly used HIPAA codes include: 

CO45: Charges exceed your contract 

PR1: Deductible Amount 

PR2: Coinsurance Amount 

PR3: Co-payment Amount 

If your organization has additional reason codes commonly used, feel free to prioritize them accordingly. 

For additional information regarding Reason code functionality, enroll in the ERA eLearning courses as 

well as reference the Electronic Remittance Advice Overview available for download from the NextGen 

Knowledge exchange. 




COB Rsn Code 


Some payers use proprietary reason codes; however, electronic secondary claims require HIPAA X12 

reason codes. COB Rsn Code replaces the proprietary reason code with a HIPAA X12 reason codes. 

This can be used instead of or in conjunction with the default COB reason code in payer maintenance. 

In the example below, the user selected DED as the reason code while in the transaction posting screen 

but the PR1 populated in the Coordination of Benefits Information window. 

The electronic secondary claim will be created using the PR1 reason code and not DED. 




Submitter Profile 


Default MSP (Medicare Secondary Payer) Type Code 

MSP Reason code (referred to interchangeably as MSP Type Code, insurance type code or the MSP 

Reason) identifies the type of other insurance specific to the beneficiary‟s MSP status. For claims billed 

electronically, the code is submitted in loop 2000B SBR05 segment of the 837P ANSI X12 4010 format. 

This code may be setup to automatically default if enabled by a Submitter Profile setting. 

*NOTE: This setting pertains only to 837P/1500 MSP claims 

In File Maintenance, after opening the Submitter Profile Library, click the Exception Options tab, scroll 

down to Subscriber Information (2000B Loop SBR Segments) - Override Insurance type code on 

Medicare Secondary/Tertiary Claims. Under the Setting column click the down arrow for a list of MSP 

type codes. 

Best Practice-Select “12 - Working Aged Beneficiary”. This type code is most likely to match what 

Medicare has on record. 




Exceptions to Default MSP Reason Code 


When the patient‟s MSP type code is different from the default setting in the Submitter Profile you may 

assign the appropriate one in the MSP Reason Code field in the encounter Insurance Maintenance 

window. 

Select the “Detail – 2” tab. On “MSP Reason Code” click the down arrow for a listing of acceptable MSP 

values and select the appropriate one for this patient. 




Payer Master File 


Master Files > System > Payer Master File > Practice Tab>Claims Sub-Tab 

First set the Secondary Media Type field to “Electronic” on the Practice Tab‟s Claims sub tab 

Verify „When Primary, force Secondary claims to Paper‟ is unchecked. 

If you also process UB (837I) secondary claims, repeat the setup on the UB Claims tab. 





Master Files >System Tab >System Tab >COB Electronic Claims 

The COB Electronic Claims sub-tab offers several options. These options should only be enabled on 

NextGen® advisement. As a System tab option, all payers across the enterprise will be affected. 

Populate 2400 CN1 contractual adjustment segment 

o Select this option to add a service line CN1 segment (2400). This amount is also referred 

to as the OTAF (obligated to accept in full) amount. If this option is enabled and a service 

line contractual adjustment exists (CAS*CO), then the allowed amount is added as the 

2400 CN1 amount. The presence of the CAS*CO segment causes the CN1 segment to 

create mimicking the allowed/approved amount in AMT*AAE 

Medicare payers should have this enabled 

Enable COB Window information popup in payment entry 

o Select this option so when this payer is secondary, the Coordination of Benefits 

Information window automatically displays when the user tabs out of the Reason field for 

the last transaction detail row 

Populate 2320 AMT*F2 patient responsibility amount segment (4010 only) 

o Select this option to add a claim level AMT*F2 segment. If this option is enabled and a 

service line patient responsible adjustment exists (CAS*PR), the patient responsibility 

amount will be added in 2320 AMT*F2. The presence of the CAS*PR segment causes 

the AMT*F2 segment to create 

Populate claim-level adjudication date in 2330B DTP*573 

o Update description to say 2330B DTP*573 

Suppress other payer detail line 2430 loop 

o No change. Functions the same way in 5010 

Populate 2320 SBR04 with primary MSP payer ID or name 

o Selection this option to add the primary payer‟s MSP payer ID or name into 2320 SBR04 





Master Files >System Tab >System Tab >COB Electronic Claims (cont’d) 

Populate 2320 claim level approved/allowed amounts (4010 only) 

o Select this option to add claim level (2320) AMT segments if the comparable segment 

exists at the service line level. This option will be sensitive to file format (professional or 

institutional) and only inserts segments appropriate to the file type 

Professional file added segments: 

2320 AMT*AAE (sum of all 2400 AMT*AAE segments) 

2320 AMT*B6 (sum of all 2400 AMT*AAE segments) 

2320 AMT*F2 (sum of all 2430 CAS*PR segments) 

Institutional file added segments: 

2320 AMT*F2 (sum of all 2430 CAS*PR segments) 

Populate 2320 CAS claim level adjustment amount (4010 only) 

o Select this option to add claim level (2300) CAS segments if the comparable segment 

exists at the service line level. These segments are the same for the different file formats 

(professional or institutional). Only one claim-level CAS segment is allowed per individual 

group code. The two most common segments are listed below: 

2320 CAS*CO sums all service line level CAS*CO segments and adds one claim 

level segment with that total. Only one instance of a claim level CAS*CO is 

allowed. If multiple CAS*CO segments exist at the service line level with different 

reason codes, they are all combined in one claim level CAS*CO with the reason 

codes repeating in fields 02, 05, 08, 11, 14, and 17. The corresponding amounts 

are placed in fields 03, 06, 09, 12, 15, and 18 

2320 CAS*PR sums all service line level CAS*PR segments and adds one claim 

level segment with that total. Only one instance of a claim level CAS*PR is 

allowed. Multiple service line PR adjustments are handled as described above for 

the CAS segment 




Practice Preferences 


Master Files > Practices > Preferences > Transactions 

Attaching Default Reason Code Library 

If a Reason Code Library is not selected on the Payer Master, the payment posting process (manual or 

ERA) will use the Default Reason Code Library selected in NextGen® File Maintenance (Master Files > 

Practices > Preferences > Transactions) Default Reason Code Library. 

Warn on COB Imbalance 

When closing the COB info entry form, a balance check will be done on the COB information. The user 

will get the following warning if there is an imbalance (Master Files > Practices > Preferences > 

Transactions) Warn on COB Imbalance. 




Free Text Line Item Reason Codes 


To free text reason codes on the transaction line during payment posting, select the option in Practices 

master file in NextGen® File Maintenance (Master Files > Practices > Preferences > Transactions) Free 

text line item reason codes. 

In the Reasons field, enter the reason code; using a comma to separate if there is more than one: 

When tabbing out of the reason code field, it will pull in the code and description from the reason code. 




COB Process Flow 


Payment posting begins with the creation of a posting batch. This document will describe the pertinent 

information required for creating a balanced COB claim under the assumption the user is proficient in 

manual transaction posting within the NextGen® application. 

Adjudication Date- Batch Header Default 

The adjudication date is the date the primary payer paid the claim. The adjudication date is an EDI 

requirement for all electronic secondary claims. 

Batch Maintenance Header 

If you are posting multiple checks in a single batch where the adjudication dates are different, leave 

Adjudication Date blank. 




Allowed Amount- Payment Entry 


The Allowed Amount is required for the secondary electronic claim to balance. If an allowed amount is 

not listed on your EOB, enter the maximum amount of the billed charge the primary payer deemed 

payable by the plan for covered services or supply rendered. 

When there are no “PR” adjustments to post, enter the charge amount as the allowed amount on the 

payment transaction line so it defaults to the COB window. This typically happens when a denial is 

received. Post the $0.00 payment transaction and enter the value of the “Billed Amount” in the “Allowed 

Amt” field in order to meet the balancing requirement with the “Allowed Amount” formula. 




Transaction Posting 


Once you have entered all the transaction information for every detail row, click on the COB button to 

access the Coordination of Benefits Information window. CPT4 codes, billed (charge amt), paid, allowed 

and reason codes will default. With the exception of the Allowed, these values are read-only and must 

be entered or corrected on the actual transaction detail row. 

Enter the corresponding adjustment amount for each reason code. 




Balancing COB Window 


Certain elements of the electronic file are required to balance. There are two balancing formulas 

associated with the COB window: 

1. Paid Amount + Sum of all Adjustments (including PR‟s) = Billed Amount (charge amount) 

2. Paid Amount + Sum of all Patient Responsibility (PR‟s) amounts = Allowed Amount 

If the allowed amount is empty, update each payment row for the COB claim to balance. 

If "Warn on COB imbalance” is checked in Practice Preferences, the system will display a message if the 

balancing calculations are incorrect: 





Adding Reason Code Lines to the COB Window 

To do so, click on the 

CPT code row so it is 

highlighted. 

Then right click and 

select New. 

May also click on the 

Norton button and select 

New. 

Once you select New, another bracket will appear on the left and the reason code field will open with the 

drop down. Select the appropriate patient responsible (PR) reason code and tab over to enter the 

corresponding Rsn Amount. 




Continue that same process 

for each CPT code row until 

all rows have a reason code 

and amount. 


If the primary insurance pays the entire charge row and no balance is left, then no reason codes 

and amounts are required. 

Once all the reason code information, their corresponding amounts and an adjudication date are 

entered, click OK to save that information. 

Screen shot here for updating Allowed amt? 





When the COB window closes, you are back on the Payment Entry screen. Click 

Recalc and then Save to save your transaction and the COB information. 




Editing Batch and COB Window 

As long as the batch is not posted, you 

may still access the COB window for 

any particular transaction. To do so, 

open the Batch Posting window and 

select your batch. Right click to display 

the menu and select Ledger. 


The Transaction Ledger will display listing all payments and transaction 

in that batch along with the associated encounter number (Source 

column). You may double-click on either the payment or adjustment to 

re-access the Payment entry screen. 





Once back on the Payment Entry, click the COB button to bring up the COB Information window where 

the reason code, amount and adjudication date fields are available to edit. 

Another way to access the COB information from Payment Entry screen is to double click on the green 

checkmark in the COB column. 

After the batch is posted, you must view or edit COB information from each individual encounter. On the 

Patient Chart, select Transactions side tab, highlight a transaction and right click to select Transaction 

Detail. 





The Payment Entry window will indicate the transaction is posted. In order to change the allowed 

amount, reason codes, amounts or adjudication date, simply open the COB window. 

Note: Changing this information after an initial claim is transmitted will result in different COB information 

in the resubmitted claim. 





When filing Medicare Secondary Payer (MSP) 837I/UB claims electronically specific codes are required. 

E.g. Condition Codes, Value Codes, Occurrence Codes. Enter these codes with their respective amounts 

on the Encounter>UB tab while posting the primary payment. The COB window does not 

Medicare has indicated overpayments occurring when a provider does not correctly indicate on the claim 

if there is a contractual arrangement between the provider and the primary payer. 

To do this, the provider must report either a Condition Code 77 or Value Code 44 and the expected 

amount. 

Shown Above: Encounter>UB>Value Codes 





Shown below: Encounter>UB>Condition Codes or Value Codes 

This information is then sent in Loop 2300 HI BE segment. Since MSP billing requirements are 

dependent upon many variables, be sure to research the MSP guidelines available at 

www.ngsmedicare.com or www.cms.gov to identify your particular service requirements. Only then you 

will know amounts to calculate, which codes to use and when they are required. 





Transaction Posting with Encounter Rate Billing 

Primary payers, such as Medicare, which are setup to split-bill an encounter rate on a UB claim to 

Medicare Part A with an alternate payer for carve-out services on a 1500 claim to Medicare Part B, may 

present some challenges with secondary claims. 

Secondary payers receiving fee-for-service on a 1500 claim will generally want to see the payments and 

adjustments from the primary payer documented on the secondary claim 

Additional documentation titled “EPM Encounter Rate Billing and Secondary Claims” has been 

created to guide you through the following: 

Process of posting transactions from a primary encounter rate payer creating a balanced 

electronic secondary claim for a fee-for-service secondary payer 

Process of posting transactions from a primary payment from Medicare Part B to the carve-out 

services to create a balanced secondary claim 

When to use the NextGen® Portal 

This information is available in the NextGen® Knowledge Exchange. 





Claim Edits & Billing - Reviewing Claim Production Status Report 

To prevent unbalanced secondary claims from creating, several claim edits are available: 

254: COB edit: Paid amount and patient responsible amounts do not equal allowed amount 

255: COB edit: All payments and adjustments do not equal billed amount 

256: Value code 39a of required for secondary institutional claim 

o Only for client‟s sending 837I 

261: Electronic COB claim requires adjudication date 

As with all claim edits, in order to prevent an encounter from producing a claim when the edit is fired, set 

the edit severity to „Required‟. 

If you set the claim edit severity to „Warning‟, you may correct the encounter and rebill before generating 

the next Secondary EDI file. Be sure to delete the previous claim generated. Otherwise two claims will 

be generated, one balanced and other unbalanced. 

COB edits will only fire if a Payer‟s Secondary Media Type is set to “Paper” and only when you are billing 

encounters. 




Generating Secondary EDI Files 


Primary claims can still be generated without affecting secondary claims. When ready to generate secondary 

claims, access the EDI File icon, click on the “Advanced” tab. Deselect the “Primary” and “Tertiary” options to 

produce secondary claims in an EDI file separately. 

BBP (Background Business Processer) 

Uncheck Primary and Tertiary field to 

generate a Secondary file separately. 

Don‟t forget your star employee “Billy Bob Processer” (BBP). BBP is dependent upon your instructions 

and guidance on assignments. When considering queuing up Batch Billing and EDI files in the same run: 

Make sure your BBP is set up only to include “Primary” claims and not secondary‟s too, since it 

requires monitoring of the Claim Production Status report for any out of balance COB claims that 

may be edited. 

Generating secondary claim files should be done manually until version 5.5.28.28 where the edits 

are included in the Claim Edit Library. 

Remember; treat BBP as you would any other employee. Check in and verify work is completed correctly 

and in the time you specified on a consistent basis. If BBP jobs fail, verify the instructions you‟ve given 

match what BBP is performing. 




NextGen® Portal 


COB functionality not currently supported may require editing secondary claims outside of the NextGen® 

application. Some clearinghouses allow you to edit secondary electronic claims with the correct 

information. Otherwise, as a workaround, NextGen® offers a free product called the NextGen® Portal. 

Instances requiring secondary claims to be edited outside of the NextGen® application: 

DT Reviewed-Not Scheduled/Problem 12370-837I UB Secondary Billing 

Missing COB Total Submitted Charges-2320 AMT*T3 segment 

DT#55372/Problem 9386-Scheduled 5.6SP2-Encounter Rate Billing & Electronic Secondary 

Encounter Rate Primary (837I/UB) and Secondary (837P/1500) 

Primary FFS (837P/1500) and Encounter Rate Secondary (837I/UB) 

Training for the NextGen® Portal is a non-billable service offered as a separate one hour WebEx 

designed for an organization‟s Core Group or Super Users. Working knowledge of payment processing, 

including the use of the COB window is a prerequisite to Portal training. 

Log a support ticket specifically requesting COB Portal training and your ticket will be routed to an EDI 

Systems Analyst for scheduling. 





Appendix A- Troubleshooting MSP (Medicare Secondary Payer) Rejections 

o CO16-This claim lacks additional information to adjudicate this claim 

MSP reason code submitted does not match what Medicare has on file due to an 

incorrect MSP code submission 

Update the valid MSP code in Patient Insurance Maintenance>Details 2 tab 

for each encounter effected and rebill 

o OTAF (Obligated to Accept in Full) record is missing 

Medicare denial for missing record 

Verify Payer Master>System>Electronic Claims> Electronic 

Secondary>Check box “Populate 2400 CN1 contractual adjustments” 

This should be checked for any Medicare type pay 

Appendix B-Defects and Enhancements 

DT#47641/Problem6809-Fixed 5.6-Multiple transactions being applied which creates additional 

transaction display pages. (i.e. Page 1 of 3): Whenever more than one type of transaction 

(payment) is applied to the same line item at different intervals, each COB window entry is added 

together incorrectly. Examples where multiple transactions can be applied: 

o Split Primary Claim Payments 

o Payment comes in and only applies to specified line items (not all) and is posted. 

Another payment is received (possibly same day) applied to other line item(s) 

o Denied Claims 

o Zero payment applied first. Claims appeal results in payment 

DT#44501/Problem 7248/Fixed 5.6- “Allowed” amount field within the COB window is not 

editable. If not entered during transaction posting or populated incorrectly by a contract loaded 

DT#42957Problem 4762-TBD-Encounter>Ins maintenance>Ability to make the MSP reason code 

a required field 

DT#45649/Problem/Fixed 5.6- Claim Bundling of like CPT codes-Utilizing “Do Not Sum Units for 

CPT 4 Code” settings in Practice preferences, Payers, or SIM 

DT#55372/Problem 9386-Scheduled 5.6SP2-Encounter Rate Billing & Electronic Secondaries 

1. Encounter Rate Primary (837I/UB) and Secondary (837P/1500) 

2. Primary FFS (837P/1500) and Encounter Rate Secondary (837I/UB) 

DT#46804/Problem 3043–Scheduled 5.6SP2-COB: Need an edit and/or warning message for 

missing adjudication date 

DT#45648/Problem 8238-TBD-Change COB Logic popup to only POP up when secondary 

insurance is attached and secondary insurance is set to paper. 





Appendix C- Handling Specialized Transactions (PQRI) 

PQRI- Physicians Quality Reporting Initiatives 

Must post as a $0.00 charge in order for the COB functionality to work as designed. When 

applying primary payment received, enter an allowed amount of 0.00 on the corresponding PQRI 

transaction and enter appropriately for any other billable charges involved. 

Within the COB window, do not add any reason codes and/or reason values associated to the PQRI rowonly 

to other chargeable line items with balances. 

Access Balance Control and check “R” for re-bill alongside the corresponding Ins2 Amt column of the 

PQRI SIM row so it will be included along with any other qualifying charge transactions(s) within the 

secondary electronic file.

Overview of Electronic Secondary Claims (COB)

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?