Earlier, Kepa Zubeldia reminded us that the "actual full name of the [WEDi/SNIP ID & Routing] group should be something like 'Trading partner identification and transaction routing' but it is way too long... Don't get confused with NPI or PayerID or PlanID issues, and that is not the topic. The 'identification' discussed in this group is the identification of the EDI trading partners represented in the ISA segment of the transactions."
To echo Kepa, we're only responsible for making recommendations for getting standard transactions from here to there based on the information in the ISA. The complications Ronald Bowron refers to, "...each claim within the transaction may have different receiver/payer data," are fortunately (I believe) not ours to deal with. If a Clearinghouse is performing aggregation, it's the CH's problem to know how to get hold of (and make itself accessible to) the providers being aggregated. We're only concerned here with the identification and routing of HIPAA standard transactions. Note that I'm making the assumption that aggregation of HIPAA standard transactions would never be done (is that correct?) - instead, the CH is taking whatever slop the (many non-HIPAA compliant) providers give it and auto-magically producing the required HIPAA standard transactions for each payer. If a provider were capable of producing HIPAA standard transactions himself (from the ISA to the IEA and the ST to SE), he would simply use the CH as a pass-through or go point to point - there'd be no reason to "aggregate." On another of Ronald Bowron's matters: is it our problem to address the authorization component between trading partners? Regardless whether one is or is not authorized to submit 837 claims to Medicare and Medicaid, why should we lose any sleep over it? If we did, would that be "scope creep"? We've done our job if we devise recommendations saying how you use the ISA to identify trading partners - and suggesting to intermediaries ways of handling routing and interconnection, along with devising specifications for advertising transport and security capabilities (for point to point). William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Ronald Bowron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, 21 January, 2002 05:31 PM Subject: Re: Payor identification codes for 837I Before attempting to apply technology to the problem, we first need to understand the existing business processes that are required to be managed and the problem we are trying to solve. It is my understanding that the ISA may only be one part of the problem. The ISA only manages sender and receiver, or point to point data transfer. Where this gets complicated further is that each claim within the transaction may have different receiver/payer data. Therefore, I believe the routing issue needs to address file, batch and transaction level routing issues. Once the appropriate levels for which routing criteria are identified, then we can discuss how each level should be managed. It is my belief that a properly defined Trading Partner table or directory could address these issues, how that table is managed or stored and accessed during processing (SQL-RDBMS, LDAP-X.500, DSML-XML Directories, ebXML Repository, .etc) should be left to the organizations to define as part of their development requirements. But the means of publicly publishing that information should be standardized (i.e. potentially via UDDI). What I'd like to see come out of this discussion list is the basic set of elements or attributes necessary to ensure the proper routing of data within the EDI framework (i.e. What should the table or directory structure contain). Another issue that needs to be addressed is the authorization component between trading partners. Medicare and Medicaid may accept 837 claims, but that doesn't mean everyone has been authorized to submit such data. Regards, Ronald Bowron
