William, I think most small providers (virtually 100% of them in vision) will be lucky to have systems even capable of constructing an interchange message, let alone one that passes all 6 or 7 levels of HIPAA testing. I have no idea what the providers whose office systems can't get them at least to an intact interchange message, are going to do... perhaps, sell Tupperware. From that point, however, I believe the software vendor is going to say, "Your new HIPAA-upgraded software will create standard claims for you, but you still need to know where to send them. For only $.50/claim, however, I will be glad to hard-wire all of your ISA sender fields to point to me. When I get your interchanges, I'll take a peek inside... first to count up the transactions to calculate your transaction fee... then I'll look at each transaction and figure out the correct/ultimate addressee. And [perhaps included in that same $.50/claim fee] I'll make sure that all acknowledgements, error reports, answering messages, and claim payments from the payors find their ways back to you in the shortest possible time".
This seems like the most logical approach for the PMS vendor because it would take doctor-vendor communications out of the HIPAA-standard loop and permit a richer, customized (XML, etc.) connection between the doctor and what looks to him like the "big HIPAA insurance messaging system in the sky". Entire "claim conversations" and "eligibility conversations" can be assembled/tracked in the doctor's local system... 835s auto-posted, etc. The burden of address discovery remains with the vendor, who is essentially functioning as the doctor's "IT department". As an alternative, however, doctors should be free to disable the send-em-all-to-the-vendor feature... perform their own address discovery... decide by themselves where each interchange should be sent... and then populate each ISA accordingly. I can also visualize third-party software similar to Seagate Crystal Decisions that a (clever) doctor could use to build his interchange messages (probably one interchange per payor) and maintain a local lookup table for the best ISA address for each payor or "plan" that he sees... thus avoiding the vendors' transactions fees by sending all messages directly to the payor or the payor's designated CH-agent. -Chris At 08:17 PM 2/9/02 -0500, William J. Kammerer wrote: >Chris: > >I'm just a populist at heart! > >But I'm also a little confused! If you (a provider) have a standard >claim transaction intended for a particular National plan ID, say >987654321, you would build a single 837 with the payer (or plan?) >indicated in the NM1 within the 2010BB loop. You would not comingle >claims for multiple payers or plans, like a CH might (as Bob Poiesz has >illustrated). > >So, who else's ID - other than the payer's - would be in the ISA >receiver field? There does seem to be a relationship when standard >transactions go from provider to payer, unmolested, via a VAN or EDIINT >software. I suppose if you've been told, via Kepa's "directory," that >claims for PlanID 987654321 go to WebMD, WebMD might demand that their >ID be in the ISA receiver field - but yet, they already know they're the >receiver! In that case, it's almost irrelevant what's in the ISA >receiver field - WebMD sounds like they're going to strip search the 837 >anyway in order to combine your claims with those of other providers >intended for whatever TPA or Payer handles PlanID 987654321. > >William J. Kammerer >Novannet, LLC. >+1 (614) 487-0320 > > >----- Original Message ----- >From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> >To: "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID & >Routing" <[EMAIL PROTECTED]> >Sent: Saturday, 09 February, 2002 07:46 PM >Subject: Re: Using a hybrid DNS > > >William, >Thanks for your ongoing concern for us "little people (providers)", but >the more I think about divorcing the payor/plan ID info in the >transactions from the receiverID info in the ISA, the more I like it... >because it embraces the models in use today in which there really is no >relationship between these two addresses. If the industry is willing to >adopt the distributed address directory model that Kepa is proposing, >then the "little people" can either hound their office system vendors to >include that capability... or the smart vendors will see the business >opportunity and sell the address discovery process to the provider as a >value-add...or the small provider can just shovel all of his claims to >one clearinghouse and let the CH worry about routing them. Since the >need to know where to send these interchanges is going to be so acute >for the provider, I can't imagine a situation in which no one was >willing to create a system that would do the address discovery for them. > >-Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
