If a clearinghouse takes in non-standard claims from providers, fails to translate them to a 100% compliant transaction and then forwards them to a payer, they would be in violation of HIPAA. As a covered entity, a clearinghouse must use a compliant standard. It may only translate from a non-standard to the standard or from a standard to a non-standard. It may not translate non-standard to non-standard. If a clearinghouse where to pass non-compliant claims to the payer allowing the payer to edit for compliance, it would be violating the law. Would it not?
Marcallee Jackson Long Beach, CA 562-438-6613 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 19, 2002 6:51 AM To: 'WEDi/SNIP ID & Routing' Subject: Re: Clearinghouse Aggregation and the ID and Routing Problem Rachel: If the "clearinghouse is [not] responsible for supplying a HIPAA-compliant transaction," when aggregation is done, then who the heck is? The clearinghouse sold a bill o' goods (to the providers) that promised taking care of all the mess of submitting claims on behalf of those providers to the payer. Presumably it's the Clearinghouse who tells the provider what is to be supplied (to submit valid claims), and it's reasonable to assume the CH would insist on the minimum amount of information for generating a HIPAA compliant transaction. That this might be a tough job is not our concern in the WEDi/SNIP ID & Routing group. This is simply a scenario portraying intermediaries, whereby the CH aggregates multiple providers' claims for a single payer. The CH is the sender - I don't think it's controversial to say its ID would be in the ISA sender field. It necessarily follows that only the CH and Payer need an electronic path (the "routing" in "ID and Routing") to each other. And should it really be up to the payer to ferret out the offending provider that caused the entire batch to be non-compliant? It seems sufficient that the payer only notify the CH of an error. Error or not, the payer should, as you urged, issue 997s - and those, again, would naturally be returned to the CH which sent (note I didn't say "originated") the transaction. In this case (of aggregation), we have a simple situation of the ISA reflecting only the CH and the payer. You could also have (perhaps the less likely) scenario where both ends are CHs - we maybe should analyze that scenario, too. I think examining scenarios like these are critical to fulfilling your initial areas of inquiry, e.g, (1) Descriptions of today's of the path/routing/addressing mechanism prevalent today (the current state), and (2) Requirements for how addressing (identification) and routing under HIPAA (the future state). Pre or Post HIPAA, I see the scenario above being equally relevant. William J. Kammerer Novannet, LLC. ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Friday, 18 January, 2002 04:54 PM Subject: RE: Clearinghouse Aggregation and the ID and Routing Problem William, I think you need to take great care in making the assumption that the clearinghouse is responsible for supplying a HIPAA-compliant transaction. The CH can't make data up out of thin air, and if they don't get all of the required data from either the provider or the payer, the CH could be assuming a huge risk if they supply missing data. Whether the provider can accept an 997 or an 824 is irrelevant when reporting error/rejection/acceptance reports. A 997 should always been sent in my opinion regardless of whether the receiver wants it or not. Regarding the ability to receive an 824 -- there are other mechanisms that can be employed to provide this type of reporting back to the provider: autofax, auto-emal, auto-generated letter via snailmail, an alert to a customer service rep to telephone the provider. Thus, I don't get hung up on having to use an X12 transaction for this. The critical need here is to get the information back to the provider in a timely fashion. That's why I keep saying that the business requirements need to be set forth first before trying to identify technical or other types of solutions. For example, if a business requirement was stated thusly: "An acknowledgment stating the results (including acceptance or rejection) of an interchange's validation against the X12 syntax rules must be returned to the originator of the interchange by the receiver of the interchange within x hours/days." then the various options for satisfying this business requirement can be identified and agreed to. Note also that when I write requirements I always try to include both a behavioral requirement (what the system or business must do) and a performance requirement (how soon, how much) so that ongoing performance evaluations can be implemented. A key question in my mind is how the industry wishes to characterize the intermediary, whether a VAN or CH. My personal opinion is that both of these types of entities are just intermediaries, and as such are never the sender or receiver....just as in the supply chain world, a VAN is never the sender or receiver, only the store-forward (or other service provider) to either the buyer or seller. I think health care is tending to get wrapped around the axle by trying to view the CH as the true originator of a transaction, when actually, the true originator of a transaction is either the provider or the payer. I think the industry needs to reach consensus on this first. Once that's achieved, then the next issue of identification (for routing and other purposes) can be tackled. Rachel
