William, I am sorry, I see that my dreaming out loud has hurt your feelings. My dreams did not include some "proprietary" sort of directory. I hope the directory can be built with open standards. Perhaps we have to start with plain HTML or XML open stuff that works today, and migrate to open standards such as ebXML once the issues concerning the open standards implementations have been addressed. I think the migration should be easy.
And, don't get me wrong, Claredi is not anxious to do this for some obscure reason. I don't think a free directory is a very profitable venture. But nobody else has volunteered to do this. Ideally, I think that someone like AFEHCT or WEDI should have done it a long time ago, but it has not happened. Probably lack of technical resources. We have the resources at Claredi. We are trying to help the industry move forward. We are willing to put our money where our mouth is. This will not be the first altruistic contribution to healthcare. And will not be the last either. But, if you think that having something imperfect, albeit useful, now could hamper the development and long term success of a better solution later, I will be glad to sit back. But we do need a solution, I think. At least for the HIPAA transition time. Thoughts? Kepa PS: As you know, I have also been contributing to your workgroups in SNIP. On Thursday 18 April 2002 12:43 pm, William J. Kammerer wrote: > I would certainly agree with Rachel Foerster that as long as folks > remain coy about advertising their capabilities in a directory, the > "information gap" will render it of limited usefulness. As time goes > on, though, I expect this reticence to subside. > > It's somewhat amusing that an industry which has, let's say, a perceived > lackadaisical attitude towards patient privacy - certainly enough to > make the U.S. Congress feel compelled to issue a voluminous privacy rule > with all its potential unintended consequences - is so secretive about > whether they "do" standard 837s, their precious "companion" guides, or > even their full names and addresses! > > Private and proprietary efforts to build a Trading Partner Profile > directory are to be applauded, as they are a valuable learning > experience. But the long term success of such an endeavor must rely on > open, interoperable standards and recommendations. That's precisely what > the WEDi/SNIP ID & Routing group, a Special Interest Group under the > Business Issues Group, is doing. We're developing recommendations for > the "auto-discovery" of trading partners (payers, providers, third-party > administrators, etc.) and their technical capabilities. Borrowing from > ebXML, we plan to devise an XML schema for an electronic Healthcare > Collaboration-Protocol Profile (CPP). CPPs will be located by Trading > Partner ID of any participant involved in HIPAA Health Care EDI - either > through a DNS-based "directory" of our own design, or possibly UDDI or > the OASIS ebXML Registry. > > Please join the WEDi/SNIP ID & Routing group by going to > http://snip.wedi.org/listserv/ and signing up for "Routing." Postings > are sent to the mailing list at [EMAIL PROTECTED] We need volunteers > who can contribute requirements and perspectives from all stakeholders: > payers, providers, clearinghouses, and third party administrators and > other intermediaries. Project documents and archives of the > [EMAIL PROTECTED] mailing list are available at the WEDi/SNIP ID & > Routing Group Web page at http://www.novannet.com/wedi/. > > This project will publish implementation guidelines for (1) the CPP to > mechanically configure communication and translation software, and (2) > automatic "discovery" mechanisms for locating trading partners' CPPs on > the Internet based on their business identifiers. > > These recommendations and specifications may someday make it easier for > your automated software - or *your* clearinghouse - to "discover" that > payer X is reached via a particular Clearinghouse B, or at a particular > FTP or SMTP e-mail address. One scenario is how the provider will use > the (future) National Plan ID on the patient's insurance card to > "discover" the EDI address of the payer to whom claims and eligibility > requests should be sent. The insurance card will contain the card issuer > number which includes the (National) plan ID; using our > recommendations, this Plan ID would be the (preferred) key to searching > for the EDI address(es) of the ultimate payer. > > The group is currently working on four "working" papers to answer > questions relevant to IDs and Routing: > > (1) Identifiers. How do you identify the sender and receiver of a > standard transaction on the ISA? How can the ISA be addressed in a > consistent way so interchanges can be delivered via intermediaries like > VANs or CHs, or point-to-point? Who are the trading partner entities > involved in exchanging standard transactions? What kind of identifiers > are available for describing these entities? What's the relationship > between the payer, plan and contract application identifiers and the > identifiers used in the ISA? > > (2) Addresses and delivery channels. How do we specify the destination > technical address and its attributes? Now do you specify type of > security - e.g., login and password, or X.509 public key certificates? > How would you accommodate scripting? How do you describe the multi-hop > path traversed between trading partners through intermediaries and > business associates? How do you describe the different "in-boxes" used > depending on transaction type? What do you have to know about a trading > partner's technical capabilities before you can send them a standard > transaction? What information does a Trading Partner Agreement contain > to answer any of these questions? What sort of communication protocols > are in use today that need to be supported? and what sort of packaging > techniques are used? > > (3) Elements of the WEDi/SNIP Collaboration-Protocol Profile (CPP): Can > a Trading Partner Agreement or "companion" document be made into a > machine-processable form? Can we use the ebXML CPP? If not as it stands, > then what changes would be needed to the CPP? How would EDI Addresses > and Delivery Channels be represented in the CPP? Can a CPP completely > supplant the need for paper TPAs? > > (4) "Discovery" of WEDi/SNIP CPPs: How might electronic CPPs be > automatically "discovered" for your trading partners? If we need a > directory for "discovery" of Trading Partners, will UDDI or the ebXML > Registry suffice? If not, can we devise our own? Who would maintain it? > > Ancillary to our technical recommendations, we're also working on the > problem getting rid of paper TPAs: if the TPA "problem," or onerous > manual EDI enrollment procedures, cannot be gotten out of the way, then > automated trading partner "discovery" has less value. Payers' > requirements for paper TPAs are a real impediment to enrollment of > providers for EDI at the moment. > > The recommendations coming out of the ID & Routing group don't have to > wait till you have "smart" auto-configurable software that can use the > XML CPP. We may develop XSLT style-sheets for displaying CPPs that have > been "discovered" via a directory which can render them in a human > readable fashion on a web browser. All the standard trading partner > setup information you'll need - including communications protocols, > URLs, EDI contact addresses, "companion" document information (e.g., > explanation of situational elements), supported transactions, security > and acknowledgement requirements, etc. - will be available simply by > providing an identifier (like a NAIC Company code, Federal Tax ID or > DUNS - or eventually the National Plan or Provider ID) of your trading > partner. So even if you have to copy and paste information from your web > browser into your existing communication and translation software, it > will sure beat paper documentation! And it will be in a consistent > format, regardless of trading partner or software vendor. > > William J. Kammerer > Novannet, LLC. > +1 (614) 487-0320 > > ----- Original Message ----- > From: "Rachel Foerster" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; "'dalegibbs'" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Thursday, 18 April, 2002 01:04 PM > Subject: RE: Vendor certification > > > Kepa, > > I think your "daydream" has value.....and if this daydream is free to > those that want to live in it, all the better! But your daydream has > much more information than what would be found in the ASCA plan, etc. > Not that I don't like your daydream! > > On the other hand, since many vendors and clearinghouses are being > extremely coy about providing any specifics to the customers about their > HIPAA compliance capabilities, this would leave, potentially, a big > information gap.... > > Rachel > > > ----- Original Message ----- > From: "Kepa Zubeldia" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; "'dalegibbs'" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Wednesday, 17 April, 2002 10:34 PM > Subject: Re: Vendor certification > > Rachel, > > <daydreaming> > > > If I was a payer, I think I would like to not just list the fact that I > have filed for an extension, but I would like to list when I am going to > be ready to accept or send the different transactions, the "tentative" > date of implementation (no guarantees), what version I am implementing > (Addenda or not) and whether I am using a clearinghouse or not. And I > would want to have the freedom to change these things, including dates, > at will without anybody getting mad at me. I think that by being open > about it, the chances for actually starting to get transactions on the > day I am ready will increase. And it will be clear that I am ready for > the 837 on one date and the 270 on another date. Hopefully the providers > can look it up and reduce my load of customer support calls. > > If I was a provider, I would like to know which of my payers are ready > and when, and what transactions I can do with them. If I have to call > their customer support department just to find out if they can take my > transactions through the clearinghouse, I don't gain administrative > simplification. Also, if I am ready to receive unsolicited 277s or 824s > (not HIPAA requirements) or 835s, perhaps I would want the world to > know, so I can start posting those things automatically. I could call > each one of my payers and ask them, but I don't have much time to do > that. So, perhaps they can look me up in the directory (automatically?) > and start the 835s coming my way. Of course, I will need to give them my > bank account number :-) > > </daydreaming> > > There may be certain value to this sort of information. At least for the > transition time. Not just the fact that they have filed for the ASCA > extension, as I assume that everybody will file for it, but to get some > of the details that will help payers, providers, and clearinghouses make > a smoother transition. > > And, if accessing the directory is free, why not? > > What do you think? > > Kepa > > > > > To be removed from this list, go to: > http://snip.wedi.org/unsubscribe.cfm?list=business and enter your email > address. > > The WEDI SNIP listserv to which you are subscribed is not moderated. The > discussions on this listserv therefore represent the views of the > individual participants, and do not necessarily represent the views of the > WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official > opinion, post your question to the WEDI SNIP Issues Database at > http://snip.wedi.org/tracking/. Posting of advertisements or other > commercial use of this listserv is specifically prohibited. -- This email contains confidential information intended only for the named addressee(s). Any use, distribution, copying or disclosure by any other person is strictly prohibited. To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=business and enter your email address. The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
