Jan, thank you for responding to my "lament". I agree with you in the most part, except for the last sentence. I think, that the answer to "how we locate a patient in the payer's system" is very simple- it is to use payer's issued ID, which is printed on every insurance card (or so I hope??). No other identification needs to be "invented". A Plan ID would be nice too, I must add. These two numbers, combined, would uniquely identify a patient in the whole world, if needed.
My short argument is: Payer pays, Payer issues IDs, Provider obtains IDs. Provider should verify eligibility information with Payer and, obtaining Member ID, should be an essential part of this process. I'm new to this list, so if this has been addressed before- no need to reply. Appreciate your time, Saulius Kerikas -----Original Message----- From: Jan Root [mailto:[EMAIL PROTECTED]] Sent: Monday, May 06, 2002 9:46 AM To: Saulius Subject: Re: FW: Subscriber vs. Dependent I can see that a strict adherence to the subscriber/dependent levels of information would create problems for an adjudication system. I agree that we should not simply replicate the paper claims environment when we move to EDI. However, that movement is always incremental and, as Angela pointed out, we do not inhabit identical universes: everyone's systems are different ("one man's ceiling is another man's floor"). The short answer to your lament is that, from a national perspective, many payer systems don't key in on the 'patient' - they only key on the 'subscriber/member/insured/whatever-you-want-to-label-them'. You may have implemented NSF in a way that was insensitive to the subscriber/dependent distinction but others did not. Benefits packages are built from an (often) entirely different logic/perspective than the claims processing perspective. For better or worse, there is no industry standard for how to locate a particular patient in a payer's adjudication/enrollment/eligiblity system(s). Jan Root Saulius wrote: > Angie, > > I see your point in using partial last and first name matching, but ... a > quick SQL Select statement (shown below) on our Member table of less than 1 > million records returned 50,000 cases when member could not be uniquely > identified (and I used full last name!): > > Select LastName, Left(FirstName,7), DOB > >From Members > Group By LastName, Left(FirstName,7), DOB > Having Count(*)>1 > > Don't get me wrong- I'm sure that your system has it all figured out and > working well, I'm just opposing the idea of my bank account transactions > being driven by name matching. Not that my name is very common, but it > does get misspelled a lot... > > Yes, everyone's using different systems, but if they are computer based, > they probably utilize some sort of unique identifier (Member ID). If they > don't- they should use paper claims. EDI standards should cater to > computers- not humans. They will be easier to implement and more accurate > in the end- everyone will win! > > Appreciate your input, > > Saulius Kerikas > Lead Aplications Developer > Beacon Health Strategies > www.beaconhealthstrategies.com > > ----- Original Message ----- > From: "Angela Dirkes" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, May 03, 2002 9:08 PM > Subject: RE: FW: Subscriber vs. Dependent > > 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. > > > > > ============================================================================ > > ==
