Welcome!

1. Welcome! It’s 2010: Did YouKnow B/AR CouldDo That? If you experience any technical difficulties or have any questions, please call:978.805.4179 or email Dana.Breeden@iatric.com This teleconference may be muted while we wait for all attendees to join. Thank you for your patience.

2. Webcast Guidelines Please be courteous to the callers on the line. Please refrain from putting us on hold. Everyone on the conference line can hear your music or announcements. Please utilize the mute function on your phone or the conference line (*6). In order to reduce background noise during the presentation, it will be necessary to mute all attendees during the presentation. Please hold your questions until the “open Q&A” period. During open Q&A periods, if you are NOT actively asking a question, please press *6 to mute your line in order to reduce background noise on the teleconference. Pressing *6 will “unmute” your line. If you have any technical difficulties, please call our technical support anytime during the session at 978.805.4179 or e-mail Dana.Breeden@iatric.com. Short survey after the webcast. Thank you and enjoy!

3. It’s 2010: Did YouKnow B/AR CouldDo That? Are you sending COB claims electronically?

4. What is a COB claim? Coordination of Benefits (COB) is used to send secondary claims in 837 format to payers Electronic data interchange (EDI) COB is predicated using two transactions – 837 and 835 Trading partners must understand EDI COB cannot be achieved efficiently without using both the 837 and 835 transactions

5. What is a COB claim? Previously, if Payer A chose not to develop the capability to send electronic remittance advices (835s), the effect was largely limited to its provider trading partners Now if Payer A chooses not to implement electronic remittance advices, it effects all other payers involved If Payer A (as a secondary payer) wishes to achieve EDI COB, they must rely on all other payers who are primary on any claim to implement the 835

6. Models of COB The 837 transaction handles two models of coordinating benefits: Model 1: Provider-to-payer to provider Model 2: Provider-to-payer to payer

7. Models of COB Model 1: Provider-to-Payer to Provider • Step 1: In model 1, the provider originates the transaction and sends the claim information to Payer A, the primary payer. The Subscriber loop (Loop ID-2000B) contains information about the person who holds the policy with Payer A. Loop ID-2320 contains information about Payer B and the subscriber who holds the policy with Payer B. In this model, the primary payer adjudicates the claim and sends an electronic remittance advice (RA) transaction (835) back to the provider. The 835 contains the claim adjustment reason codes that apply to that specific claim. The claim adjustment reason codes detail what was adjusted and why.

8. Models of COB Model 1: Provider-to-Payer to Provider • Step 2: Upon receipt of the 835, the provider sends a second health care claim transaction (837) to Payer B, the secondary payer. The Subscriber loop (Loop ID-2000B) now contains information about the subscriber who holds the policy from Payer B. The information about the subscriber for Payer A is now placed in Loop ID-2320. Any total amounts paid at the claim level go in the AMT segment in Loop ID-2300. Any claim level adjustment codes are retrieved from the 835 from Payer A and put in the CAS (Claims Adjustment) segment in Loop ID-2300. Claim level amounts are placed in the AMT at the Loop ID 2320 level. Line Level adjustment reason codes are retrieved similarly from the 835 and go in the CAS segment in the 2430 loop. Payer B adjudicates the claim and sends the provider an electronic remittance advice.

9. Models of COB Model 1: Provider-to-Payer to Provider • Step 3: If there are additional payers, step 2 is repeated with the Subscriber loop (Loop ID-2000B) having information about the subscriber who holds the policy from Payer C, the tertiary payer. COB information specific to Payer B is included by running the Loop ID-2320 again and specifying the payer as secondary, and, if necessary, by running Loop ID-2430 again for any line level adjudications.

10. Models of COB Model 1: Provider-to-Payer to Provider 835 RA from Payer A Payer A Primary Payer B Secondary First 837 Claim Provider Second 837 Claim 835 RA from Payer B

11. Models of COB Model 2: Provider-to-Payer to Payer • Step 1: In Model 2, the provider originates the transaction and sends claim information to Payer A, the primary payer. The subscriber loop contains information about the person who holds the policy with Payer A. All other subscriber/payer information is included in Loop-ID 2320. In this model, the primary payer adjudicates the claim and sends an 835 back to the provider.

12. Models of COB Model 2: Provider-to-Payer to Payer • Step 2: Payer A reformats the 837 and sends it to the secondary payer. In reformatting the claim, Payer A takes the information about their subscriber and places it in Loop 2320. Payer A also takes the information about Payer B, the secondary payer/subscriber, and places it in the appropriate fields in the Subscriber Loop 2000B. Then Payer A sends the claim to Payer B. All COB information from Payer A is placed in the appropriate Loop 2320 and/or 2430. • Step 3: Payer B receives the claim from Payer A and adjudicates the claim. Payer B sends an 835 to the provider. If there is a tertiary payer, Payer B performs step 2.

13. Models of COB Model 2: Provider-to-Payer to Payer 835 RA from Payer A Payer A Primary Payer B Secondary First 837 Claim Includes all information on other insurers involved in this claim. Provider Claim has been reformatted to place Payer B info in “Destination Payer” position and Payer A info in COB loops. 835 RA from Payer B

14. COB: Claim Level vs. Line Level Claim Level Adjustments: • Reports adjustments in 2300 loop to pertain to entire claim • Usually reported on INP claims but can be used on OP claims • Line Level Adjustments: • Reports adjustments in 2420 loop per individual Service Line Item • Usually reported on OP claims

15. Balancing a COB Claim • There are several 837 loops that need to be accurate in order to correctly balance a COB claim • Line level example: TOTAL CHGS : $150 LX*1~ SV2*0305*HC>85610>QW*16*UN*1~ DTP*472*D8*20090721~ SVD*121*5.74*HC>85610>QW*0305*1~ CAS*CO*45*10.26*1~ DTP*573*D8*20090810~ LX*2~ SV2*0519*HC>99211*134*UN*1~ DTP*472*D8*20090721~ SVD*121*48.86*HC>99211*0519*1~ CAS*CO*45*72.92*1~ CAS*PR*2*12.22*1~ DTP*573*D8*20090810~

16. Balancing a COB Claim CLM*BAW45682*18836.81***11>A>1*Y*A*Y*Y*********Y~ TOTAL CHARGES AMT*C5*1068~ PAYER AMOUNT DUE SEGMENT CAS*CO*45*13275.22*1~ CLAIM LEVEL ADJUSTMENT CAS*PR*1*1068*1~ CLAIM LEVEL ADJUSTMENT AMT*C4*4493.59~ PRIMARY PAYER PAID AMOUNT • There are several 837 loops that need to be accurate in order to correctly balance a COB claim • Claim level example: • (18836.81) – (13275.22) – (1068) – (4493.59) = 0.00

17. MEDITECH and COB Rule #1: • You must be processing the primary payer 835 through MEDITECH’s EDI Programs • Without this, the Claim Adjustment Reason Codes will not pass to the COB claim

18. MEDITECH and COB Common Issues • Hospital bills different HCPCS per payer • If the HCPCS doesn’t match exactly from Primary to Secondary payer, the CAS codes will not produce on the COB claim • Primary payer returns different information than what was originally billed • If the payer returns a different revenue code (i.e. 3 digits versus 4 digits) and that does not match what is on the COB claim in MEDITECH, COB information will not generate

19. MEDITECH and COB Common Issues • If the primary payer has paid on bill #1 and that bill has since been reversed in MEDITECH, a COB claim for bill #2 will not generate COB segments • If the primary payer does not pay on the 835 (i.e. pays via paper remit), MEDITECH will not produce a proper COB claim • MEDITECH has indicated there is currently no workaround for this situation (the primary not paying electronically).

20. MEDITECH and COB Possible Workarounds • Use MEDITECH’s Online Claim Editor • This method is recommended by MEDITECH to edit COB claims that do not generate correctly • To use this function, you must have working knowledge of the 837 format • I do not recommend billing staff use this routine as it could cause a lot more issues with 837 files bombing, etc.

21. MEDITECH and COB Possible Workarounds • Use a clearinghouse or 3rd party billing software • A COB claim can be edited to include COB information once uploaded into a clearinghouse or 3rd party billing software. Users will need to know adjustment information • Editing should include input of a Claim Level Adjustment Code.

22. I Can Help! Greg Kalivas Independent MEDITECH Financial Systems Consultant GKal Consulting Phone: (978) 682-2323 E-mail: gkalivas@gkalconsulting.com Website: http://www.gkalconsulting.com

23. B/AR Survey says: Please take the survey that appears when you close your Internet Browser after this webcast. You could win a $100 VISA Gift Card. Blogs: On Focus – http://focusblog.iatric.com Patient Privacy Matters – http://securityblog.iatric.com For more information: Please contact your Iatric Account Manageror send an email to info@iatric.com Survey/ Contact Us