William, SBR02 as you noted is indeed situational, but also describes the following claims associated with this particular subscriber, so if you have subscriber claims following as indicated in the HL segment, you must have SBR02 value of 18. Now the SBR02 note says if the subscriber and the patient in the following claim(s) are not the same, SBR02 must be blank, so this eliminates the possibility of having a subscriber claim immediately following and then dependant claims following that claim as SBR02 cannot hold the value of 18 or blank at the same time. The only way around this is to have a subscriber loop for each claim, UNLESS it is only dependants claims involved and the subscriber him/her self does not have a claim.
David G. Foulke Senior Analyst Dairyland Healthcare Solutions 320-634-5331 [EMAIL PROTECTED] http://www.dhsnet.com -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 1:17 PM To: WEDI SNIP Transactions Workgroup List Subject: Re: 837 Subscriber and Patient Loops I'm left knocking my head figuratively against the wall on this one! I don't see how the note on SBR02 keeps you from using John Goetz' "Option 1," whereby a subscriber has both claims itself along with subordinate "patients" (or dependents) with claims. The note says SBR02 is "Required when the subscriber is the same person as the patient..." Is it just a matter of a definite vs. an indefinite article? - i.e., "same person as *the* patient" vs. "same person as *a* patient." That's getting really obtuse, if so. I simply read "same person as the patient" to mean that a 2300 claim loop is included within the 2000B Subscriber HL - nothing more or less. It certainly can't mean the 2000B Subscriber HL is the same as the 2000C Patient HL, which would be the literal interpretation of the note - and which is also patent nonsense! If there are claims in the 2000B Subscriber loop, the subscriber is *the* patient. Period. It hardly matters that there are other patient (or dependent) HLs subordinate to the subscriber HL - that's an entirely separate issue (and loop). I can't see how it's any harder for a payer to process either "option." A payer would probably have had to actually work at it to make Option 1 not work! Nor does there seem to be anything wrong with either the front-matter or the notes as they are now. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Tom Drinkard" <[EMAIL PROTECTED]> To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> Sent: Thursday, 20 March, 2003 03:44 PM Subject: RE: 837 Subscriber and Patient Loops Ed, We disagree. The front matter in the implementation guides (all three guides illustrate option one) will be corrected for version 4050. In the meantime, I would suggest that those entities who submit claims only use option two, since it will be compliant in all cases. It would be nice if those entities who receive claims support both options, since that will optimize the transaction flow, but that is wishful thinking. This discrepancy has been discussed at length by the 837 workgroup at X12N. The conclusion of the group is that the front matter is incorrect and the pages in the transaction listing (Section 3) is the only technically correct option. Hope this helps. Tom Drinkard EDIT, Inc. [EMAIL PROTECTED] (678) 795-1251 (voice) (775) 458-6117 (fax) -----Original Message----- From: Ed Stroot [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 3:35 PM To: Tom Drinkard; WEDI SNIP Transactions Workgroup List Subject: RE: 837 Subscriber and Patient Loops Tom, I beg to differ. Both options are correct. Option 1 is described exactly in the front matter for the 837P (see 2.3.2.1, the HL example for SUBSCRIBER #4 AND PATIENT #P4.1). Option 1 is not usually used, but is correct. We see it used for dental claims. It took some work by my developer, but he figured out how to keep it all straight. Ed Stroot -----Original Message----- From: Tom Drinkard [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 1:02 PM To: WEDI SNIP Transactions Workgroup List Subject: RE: 837 Subscriber and Patient Loops Option two is the only correct option. There is a conflict with SBR02 (Relationship Code) in the 2000B loop. It is situational with the following note: "Required when the subscriber is the same person as the patient. If the subscriber is not the same person as the patient, do not use this element." In order to satisfy the above requirement, you must repeat the subscriber information. Hope this helps. Tom Drinkard EDIT, Inc. [EMAIL PROTECTED] (678) 795-1251 (voice) (775) 458-6117 (fax) -----Original Message----- From: Goetz, John [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 1:31 PM To: WEDI SNIP Transactions Workgroup List Subject: 837 Subscriber and Patient Loops I have a question regarding subscriber and patient loops in the 837. If a healthcare provider bills claims for both the subscriber and the subscriber's dependent in the same 837, how should the subscriber and patient loops be arranged? Option 1 2000B - SUBSCRIBER HIERARCHICAL LEVEL 2010BA - SUBSCRIBER NAME, ADDRESS, DEMOGRAPHIC 2010BB - PAYER NAME 2300 - CLAIM INFORMATION 2000C - PATIENT HIERARCHICAL LEVEL 2010CA - PATIENT NAME, ADDRESS, DEMOGRAPHIC 2300 - CLAIM INFORMATION Option 2 2000B - SUBSCRIBER HIERARCHICAL LEVEL 2010BA - SUBSCRIBER NAME, ADDRESS, DEMOGRAPHIC 2010BB - PAYER NAME 2300 - CLAIM INFORMATION 2000B - SUBSCRIBER HIERARCHICAL LEVEL 2010BA - SUBSCRIBER NAME, ADDRESS, DEMOGRAPHIC 2010BB - PAYER NAME 2000C - PATIENT HIERARCHICAL LEVEL 2010CA - PATIENT NAME, ADDRESS, DEMOGRAPHIC 2300 - CLAIM INFORMATION In option 1, the patient hierarchical level starts immediately after the subscriber's claim data. In option 2, the subscriber level must be repeated after the subscriber's claim data and before the dependent's claim data. Which one is the correct option when a provider submits claims for both the subscriber and the subscriber's dependent in the same 837? Thank you, John Goetz HIPAA Project Manager ACS State Healthcare --- The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
