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 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 17, 2002 6:39 PM To: WEDi/SNIP ID & Routing 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.
