There are other business scenarios that a claim might be rejected that the CH would have to get additional info from the provider for example a non-covered procedure. I would think it would be easier for everyone if the claims were spit apart by provider in this scenario. Dave Frenkel ----- Original Message ----- From: William J. Kammerer <[EMAIL PROTECTED]> To: WEDi/SNIP ID & Routing <[EMAIL PROTECTED]> Sent: Thursday, January 17, 2002 4:38 PM Subject: Clearinghouse Aggregation and the ID and Routing Problem
> See Kepa's posting to HIPPAlive of Wednesday, 26 December, 2001. In > order to save you the trouble of searching through the archives, I've > attached the e-mail. > > In Kepa's aggregation scenario, the provider(s) are not using HIPAA > compliant transactions - and therefore would not be able to accept a 997 > (or 824 or whatever) even if the CH could discern which provider was > responsible for dirty data (thus causing the payer to reject the entire > aggregated 837). > > But in any event, I would expect the CH to always supply HIPAA compliant > data even if the claim were aggregated from hundreds of claims from > different providers. The CH *is* responsible for HIPAA compliant data - > the little, innocent provider is paying the CH to be insulated from the > complexity of EDI and HIPAA standard transactions. If the CH were to > send non-compliant data (if only within one claim within hundreds of > otherwise valid claims), the payer will send back an 824 (if one is ever > devised) and the CH will have to work back from the technical error data > to come up with the provider in question, so the errant provider's claim > can be suspended without holding up the others. > > If a CH can't solve this problem on its own, it will just have to send > one 837 for each provider - one of the options Kepa suggested. Would it > really be any but the payer's problem if the payer's translator could > not handle the increased number of ST-SE pairs? In either case (whether > aggregated or split per provider), as the intermediary, the CH is the > ISA sender (or receiver) - it's up to the CH to look inside the > transaction to see who the pay-to provider is. > > Is Kepa's scenario an ID or routing problem we have to worry about? > > William J. Kammerer > Novannet, LLC. > >
