Somehow the last part of my post was lost (I must have clicked when I should have pointed), so let me try again:
I have been convinced by the erstwhile Mr. Kammerer to participate in the WEDI/SNIP EDI addresses and TPA discovery projects, and to bring the perspective of the vertical market software developer. I am a software developer, currently focused on the healthcare provider's desktop, specifically the desktops of the 300K+ or so small healthcare providers who may want or need to do something to be in compliance with the mandates of the 1996 HIPAA. I have been working with ANSI and EDIFACT EDI since 1983/1984 or so, and once I, too, held to the "dream" of electronic buisness without the need for bilateral Trading Partner agreements. I think I finally let that dream die in about 1995, when I had encountered just one too many variations in implementation standards for the most common of business documents (POs, Invoices). Having browsed the archives for the last month worth's of postings, I notice that a great deal of focus is being placed on the ANSI EDI requirements of the 1996 HIPAA - even though the one-year extension on implementation recently enacted by our Congress puts the "drop dead" date out to October, 2003. If we assume that the focus here is going to be on the implementation of the HIPAA-mandated document standards, the dream is rising from the dead: Since everyone will use the same implementations, all we really need is EDI addresses and which transaction sets and implementation version(s) is(are) supported. (More on these versions in a minute or so). As a consultant and developer, here is what I would like to do: Similar to the NIST "whois" web site (identify the owner of an internet domain name), I would like to be able to look up a plan (payer) by some publically available number, and ask for a list of transaction sets and implementations supported, as well as Interchange Identifier, Functional Group Identifier, preferred (or acceptable) delimiter characters, and routing (VAN, direct dial phone number, FTP site). The plan ID would seem to be the national payer ID, but those are not ready yet. However, there is NAIC for insurance firms; and AM Best Co. publishes the DUNS number for insurance companies. My "request" could be .. <SEND ME INFO FOR> DUNS|NAIC|NPID 1234567890 == THIS NEXT SECTION WAS OMITTED FROM THE POST== This can be done under control of an application program, permitting developer to provide "inquiry" to a user -as in, "Does this payer provide realtime eligibility checking? (See the X092 HIPAA specifications for more on real-time vs. batch eligibility checking). The response would be some formatted data, perhaps in XML (since everyone seems to be in love with XML), sort of like this: <PLAN> <NAME>Official Name of Plan</NAME> <ADDRESS>MailingAddress</ADDRESS> <NPID>NatlPayerId</NPID> <NAIC>NAIC#</NAIC> <VAN>GEIS</VAN> <ISAQUAL>01</ISAQUAL> <ISAID>123456789</ISAID> .. more static info <TRANSACTIONS> <RECEIVE> <837> <IMPLEMENTATION>X096 <ACCEPTED>NO</ACCEPTED> </IMPLEMENTATION> <IMPLEMENTATION>X097 <ACCEPTED>YES</ACCEPTED> <MAXDETAIL>500</MAXDETAIL> <GROUPID>12345</GROUPID> </IMPLEMENTATION> </837> </RECEIVE> .... </TRANSACTIONS> </PLAN> Include each document type mandated by the HIPAA; the plan indicates which documents it accepts, and if so, the functional group identifier needed (I got ten bucks someone will want a different ISA identitifier, so we'd better figure on that), and other information about this plan's use/acceptance of the ASNI version of the document. Subject to some fleshing out, this is all any competent developer *should* need to handle the "discovery" - at least insofar as getting the technical details. One of the biggest problems which will occur is in the commercial arena is if no uniform/universal identifier for providers is available. From the payer systems on which I have worked, without THAT PAYER's PROVIDER ID nothin happens at all! But why not have the same discovery process for the use of payers? That is, every provider provides the same type of information to payers on request? Which documents they accept, EDI addresses, etc, national provider ID, Duns number, etc. This is just something to get the ball rolling. The practical limitations include: 1. Already the published HIPAA standards have multiple versions. (X091, X091A and X091A1 are available for the 835, although I don't think having multiple versions has a practical effect right now). 2. Just looking through the standards, I can tell some payers and probably pre-pricers as well are going to want more data. This means more versions. 3. Payers are going to be reluctant to cut checks to unseen cyber-only-entities. 4. (A BIGGIE) There is no provision for security or encryption; and you can't very well start issuing user id's and passwords on an "open" platform. There are already a host of ANSI EDI documents designed to generically define the electronic evenironment: 816 Organizational Relationships, 101 Name and Address Lists, 838 Trading Partner Profile, 868 Electronic Form Structure, and others. I see no reason we should not have some kind of "Health Care Plan or Provider Electronic Capabilities" document defined, similar to the above. === END OF PORTION OMITTED EARLIER === Also, it was pointed out that the ID you saw, "PPPS_INFO" is not exactly user-friendly. Well, I never supplied that information on the "join" - PPPS_INFO is the "user friendly" (to my mail administrator) identifier of a mail account on my domain/web site. I think I saw something on how to override that in my mail software instructions....let's see how this one turns out.... Michael Mattias Tal Systems, Inc. Racine WI [EMAIL PROTECTED]
