1. Welcome! 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. It’s 2010: Did You Know B/AR Could Do That?

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 You Know B/AR Could Do 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 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. Model 1: Provider-to-Payer to Provider

8. Models of COB 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. Model 1: Provider-to-Payer to Provider

9. Models of COB 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. Model 1: Provider-to-Payer to Provider

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

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

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. 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~ 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:

16. 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 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 Balancing a COB Claim

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 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 Common Issues

19. MEDITECH and COB 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). Common Issues

20. MEDITECH and COB 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. Possible Workarounds

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

22. I Can Help! Greg Kalivas Independent MEDITECH Financial Systems Consultant GKal Consulting Phone: (978) 682-2323 E-mail: gkalivas@gkalconsulting.comgkalivas@gkalconsulting.com Website: http://www.gkalconsulting.comhttp://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 Manager or send an email to info@iatric.com Survey/ Contact Us