The WEDi/SNIP ID & Routing group, a Special Interest Group under the Business Issues Group, is 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 WEDi/SNIP 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.
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, relevant to Peter Barry's other work involving the National Plan ID, is how the provider will use the number 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 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? 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 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 RegRep 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" 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-reconfigurable 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 or DUNS) 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. Please join the discussion by sending e-mail to [EMAIL PROTECTED] containing the word "join" (sans the quotes) in the body. Postings are sent to the mailing list at [EMAIL PROTECTED] We desperately 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/. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ********************************************************************** To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=business and enter your email address.
