Saulius, Not all textual information is useless. Our "member matching" logic uses a partial lastname, firstname in conjunction with the DOB when we do not have an exact match in our system by first using the Member ID and DOB. This type of logic prevents many claims from be rejected for not finding the member in our system. Although, I agree that Subscriber information is unnecessary as we do not use this at all.
No matter what, it will always be difficult for everyone to agree on any standard since everyone's using different systems. What works for one is probably a big headache to the next person! Angie Dirkes Systems Analyst Sharp HealthCare [EMAIL PROTECTED] -----Original Message----- From: Saulius [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 9:47 PM To: [EMAIL PROTECTED] Subject: RE: FW: Subscriber vs. Dependent Jonathan, I totally agree that Subscriber infomation is not needed and I would go even further by stateing that the only information computer needs about a member in order to pay a claim, is patient's MemberID, DOB (to ensure that correct ID is used), PlanID and provider's Patient No (as a courtesy to provider). All other textual information, like First, Last, and Group name is useless to computer. Another source of confusion and unecessary complexity, it seems, is multiple locations for the same data, for example, there are many same data elements on the claim level as well as claim line (or Provider and the Claim). Getting rid of such "umbrella" and at the same time "overridable" fields would greatly simplify creation and importing of the files- there would much less chance for various interpretations of the data and IG itself. In general, (for the lack of time, I won't go into details), there are too many "if this then do that or you could do that.." and, as we see, just from this newsgroup alone, there's a huge need for more "if this then do that" explanations. What I'm trying to say is, that for all this (EDI) to work, the Implementation has to be more "computer friendly", meaning, rigid. Information should not be allowed to optionally appear at different places .. or "float". We should not mimic our human readable paper claims. Just my two "computer programmer's" cents, Saulius Kerikas Lead Aplications Developer Beacon Health Strategies -----Original Message----- From: Jonathan Fox [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 4:07 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FW: Subscriber vs. Dependent Jan, We are a payer in Western NY and are having a bit of a problem with our software vendor in regard to this issue. They built their processes in "strict" adherence to the subscriber / dependent levels of information. This presents a HUGE problem from a servicing/flexibility standpoint for us. If a claim is received with a dependent member's information in the subscriber loop, the claim will not process. I feel that the healthcare industry is underestimating the impact of the introduction of the subscriber and dependent loops of the X12 transaction sets. The old NSF and UB92 formats do not differentiate to this (unnecessary) level. Why can't there simply be 1 (one) patient level? All thoughts and opinions are welcome!!! Thanks. Jonathan Fox eCommerce Analyst Independent Health CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. >>> Jan Root <[EMAIL PROTECTED]> 04/30/02 12:26PM >>> I would echo what Rachel said and add that mis-identification of subscriber and dependent happens all the time, today. Patients are often unaware of whether they are a 'dependent' or a 'subscriber' on a plan. The provider submitting the eligibility inquiry or claim takes their best shot at guessing. Payers are free to be strict and reject/deny transactions where the individual is mis-identified, or to be more lenient and, if they can match the individual somewhere in the member files, go ahead and process the transaction. The 'price' of rejecting a transaction for misidentification will probably be a phone call so it may be to the payers' economic advantage to persue a more lenient policy, at least part of the time. Jan Root Rachel Foerster wrote: > Alex, > > For something misidentified in this manner, you would have to make your own > determination as to what response you would give back...but, again, I would > think that if given the information provided on the inbound 270 you can be > certain you've identified the correct individual in your system, why not > return a meaningful answer. After all, the intent here is to avoid requiring > the provider to make a phone call. > > In any case, it's still a business decision as to what you want to do in the > scenario you describe. > > Rachel > > -----Original Message----- > From: Alex Chernyak [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 29, 2002 10:30 AM > To: [EMAIL PROTECTED] > Subject: RE: Subscriber vs. Dependent > > And how about when the provider marks the subscriber as a patient (2100D) > but submits the details for a dependent (2200E) or vice versa? > > >>> "Rachel Foerster" <[EMAIL PROTECTED]> 04/25/02 09:15PM >>> > Jonathan, > > I'm sure/hope others here will also respond, but here's my take on your > questions: > > 1. If the patient is NOT the subscriber, the patient HL should be created, > even in the absence of knowing the member id for the patient. If the patient > is the subscriber, then ONLY the subscriber HL should be created with as > much identifying information as can be obtained, keeping in mind the minimum > data required for subscriber/patient identification. > > 2. If the information source can accurately and unequivocally ascertain that > the individual being queried about is the same individual in their system, I > would recommend responding even if the individual is not the subscriber, but > putting the individual's information in the appropriate HL structure. > > Of course, in both cases, you'd have to determine your own business rules > for these responses, since the implications could be different if the query > was for eligibility versus authorization/referral. > > Rachel > Rachel Foerster > Principal > Rachel Foerster & Associates, Ltd. > Professionals in EDI & Electronic Commerce > 39432 North Avenue > Beach Park, IL 60099 > Phone: 847-872-8070 > Fax: 847-872-6860 > http://www.rfa-edi.com > > -----Original Message----- > From: Jonathan Fox [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 25, 2002 5:13 PM > To: [EMAIL PROTECTED] > Subject: Subscriber vs. Dependent > > I have a question regarding the X12 transaction sets named under HIPAA that > use the subscriber and dependent HL structure. More specifically the > inquiry/response transactions. > > If the information receiver (provider) does not know the patient's member > id, how should they build the transaction set? Should they put the patient > information at the subscriber or the dependent level? > Likewise, if the inquiry comes in at the subscriber level, and the member is > NOT the subscriber, should we respond? > > Any guidance would be greatly appreciated!!! > > Jonathan Fox > eCommerce Analyst > Independent Health > > CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain > confidential information which is privileged and protected from disclosure > by Federal and State confidentiality laws, rules or regulations. This > e-mail and attachments, if any, are intended for the designated addressee > only . If you are not the designated addressee, you are hereby notified > that any disclosure, copying, or distribution of this e-mail and its > attachments, if any, may be unlawful and may subject you to legal > consequences. If you have received this e-mail and attachments in error, > please contact Independent Health immediately at (716) 631-3001 and delete > the e-mail and its attachments from your computer. Thank you for your > attention. > > -------------------------------------------------------------------------- -- > -- > CONFIDENTIALITY NOTICE: This message is intended only for the > use of the individual or entity to which it is addressed and may contain > information that is privileged, confidential or exempt from disclosure > under applicable law. If the reader of this message is not the intended > recipient or the employee or agent responsible for delivering the message > to the intended recipient, you are hereby notified that you are strictly > prohibited from printing, storing, disseminating, distributing or copying > this communication. If you have received this communication in error, > please notify us immediately by replying to the message and deleting it > from your computer. Thank You, Antares Management Solutions. > > ============================================================================ > ==
