I have been following this tread for some time and am fascinated over the amount of time being dedicated to the ISA Receiver ID. It really does not matter what the ISA Qualifier and Receiver ID are since they will be used as a key to look up an EDI address and routing information. As long as the information has been set up as a key in the table (or database) so people can find it, who cares what it is? Can we agree that whatever the IG defines as possible entries is fine with us and get on with the process of defining EDI Addresses and routing techniques.
Dale Gibbs E-COM Advisor 614.871.2314 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 9:29 AM To: 'WEDi/SNIP ID & Routing' Subject: Re: A proposed work plan for this group We need consensus on the following issues: (1) Agreement that global IDs are to be used for all parties (providers, payers, TPAs, repricers, billing agents, clearinghouses, etc.). One or more IDs - from one or more of the supported domains on the ISA - may be used, chosen by the party being identified. (2) Agreement that the ZZ qualifier is not to be used on the ISA. This necessarily eliminates the use of proprietary payer or CH assigned provider IDs. (3) And possibly, agreement on how the GS is to be used for internal routing or selection between alternate "EDI addresses." Aren't these the highest priority issues to resolve? Because if we don't have a consistent way of addressing partners (based on IDs), there's really no good way to do anything else, such as the lookup of partners' information in a directory. And it's that directory (whether a DNS lookup, ebXML Registry or UDDI) that contains the CPP which has all the good stuff for automatic trading partner hook-up. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Saturday, 06 April, 2002 02:37 PM Subject: A proposed work plan for this group The dominant business model in health care is: 1. For the most part, only health care claims are submitted electronically by providers to the party they've determined is the financially responsible party for reimbursement. 2. The format used for electronic claims is most often the NSF batch file format, or some variant thereof. 3. It's not typical that a provider submits claims directly to the financially responsible party. Rather, intermediaries are more likely than not to be in the picture. Intermediaries can be clearinghouses, TPAs, repricers, billing services, and so on. 4. These intermediaries typically determine the financially responsible party by interrogating data contained with the batch file. 5. While the NSF batch file has batch header and trailer records which start/end the batch, the records in the batch are fixed field/fixed record multiple record types. 6. The industry does not use the typical EDI VAN store and forward model. Thus, it has not built an infrastructure that uses an identifier from a batch header record to "mailbox" files for the receiver. 7. The industry model is one of the provider always have to "push" electronic claims to the financially responsible party through an intermediary and to then "pull" any return messages. 8. Other types of information exchanges, queries, referral requests, etc., are most often performed via phone, IVR, DDE, or fax. Thus, today's application systems do not typically support nor enable batch file transfers for these types of information exchanges. As you know, the model which most other industries use for standards-based EDI exchanges is one where the receiver of the interchange maintains a mailbox at some "post office" - most often called a VAN. Thus, both parties to the information exchange maintain their own mailboxes (or multiple mailboxes) at a post office(s) of their choosing. It's this model that the current X12 control structures enable and support. It's my opinion that the urgent problem to be addressed and solved **before April, 2003** is how to complement the current business model **using the X12 Interchange control envelope** for the submission of claims and without forcing the entire industry on its head...there are sufficient challenges with just adopting a new set of formatting rules and standard data. Coming up with a "down and dirty" (if necessary) solution that will enable the industry to become operational today should be the urgent priority of this group. It's my perspective that there has been excellent brainstorming and discussions over the last several months on a variety of issues for EDI addresses, identifiers, etc. on this list. But, the clock is ticking and time is fast running out for this group to provide direction to the industry to solve the immediate problem. It's now time to turn to: 1. Developing a clear and succinct statement of the problem(s) to be solved. Prioritizing the identified problems. 2. Developing a set of functional requirements that will solve the problems identified using today's tools. 3. Transforming the problem statement(s) and requirements into a document that can be provided to the industry fast so that the industry can use it now. I propose that this group spend no more than the next 2 weeks to reach consensus on the problem(s) that must be solved now. Following that develop a set of functional requirements for **each** problem identified - spend no more than 2 weeks on this task. These two tasks should be completed by May 3rd. During May the recommendations/specifications/guidance document can be developed...I would certainly expect that the final draft of this document could be completed by the end of May. Comments? Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070
