William, Would it be possible to 'guesstimate' the representation on the ID & Routing group to see what segments are not represented or under represented? Maybe start with payer/provider/vendor. Thanks.
I just received it in the mail, the cover story in the Washingon Technology magazine(www.washingtontechnology.com) is about HIPAA IT services. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 11:43 AM To: [EMAIL PROTECTED] Subject: I have a Dream: Directories 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. 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.
