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. > > ============================================================================ > ==
