I would like to make a motion that our proposals be designed specifically to meet the business needs of INDIVIDUAL PROVIDERS wishing to directly communicate with INDIVIDUAL PAYORS.
My reasoning: Some of our inability to reach clear consensus appears to be fuzziness about the intended target audience for our address discovery schemes and any "best practices" recommendations, such as who the "ISA receiver" should be, bundling transactions destined for different receivers, etc. If our work products are well suited to 2-way communication between "little providers" and "big payors", however, they may also be of interest to middleman entities like VANs and CHs who are interested in creating services for doctors. Given the variety of current business practices among existing middleman-players, however, I think it would be a mistake for this group to attempt to "support" in our recommendations what these guys are doing today . If we limit our scope as suggested, we will be writing specifications to support a business model that has not yet emerged in the marketplace: lots of small providers sending/receiving directly with lots of individual payors. In fact, massive "direct connect" EDI may never emerge in healthcare IF the middleman industry does a terrific job of packaging up simple, cost-effective solutions for offloading this headache from the doctors. From the doctors' point of view, they have to PAY SOMEONE to work this magic and they could give a rat's butt whether it was a "VAN", a "CH", or a $20,000 software upgrade... just so Suzy knows which button(s) to push and they eventually get paid! Comments? Regards, Chris >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 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
