Walt: I don't know if there's much going on within the XML EDI workgroup - we'll have to wait for David RR Webber or Alan Kotok to tell us more. But I see that you, being from an "innovative BCBSFL and Humana joint venture" and also involved in WEDI, may very well be interested in what we're doing in the WEDI/SNIP ID & Routing group with respect to ebXML.
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. I'll be in Denver at the WEDI 2002 National Conference next Wednesday to present a short slideware overview of the Healthcare CPP and 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 Healthcare 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 Healthcare 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 Trading Partner Agreements (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. The CPP will contain all the standard trading partner setup information of your trading partner you'll ever need. It will include communications protocols, URLs, EDI contact addresses, "companion" document information (e.g., explanation of situational elements), supported transactions, security and acknowledgement requirements, etc. The CPP will be located in the Registry simply by providing an identifier (like a NAIC Company code, Federal Tax ID or DUNS - or eventually the National Plan or Provider ID). 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. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "XMLEDI Group" <[EMAIL PROTECTED]> Sent: Friday, 10 May, 2002 09:14 AM Subject: Re: Topics Greetings, I would like to echo the comments made by Jack0824 in that the only emails that seem to come through as of late are the ones from folks trying to unsubscribe.. Is there current activity within the XML EDI workgroup? Allen any thoughts? Have a great TGIF.. Walt Culbertson Chief Technology, Security and Privacy Officer Availity, L.L.C. (An innovative BCBSFL and Humana join venture) Jacksonville Office: 904-861-2903 www.availity.com Chair, Southern HIPAA Administrative Regional Process (SHARP) A Public & Private Partnership with HHS, CMS (HCFA) and HRSA www.sharpworkgroup.com Co-Chair - Security & Privacy, Workgroup for Electronic Data Interchange (WEDI), Strategic National Implementation Process (SNIP) www.wedi.org --- You are currently subscribed to xmledi-group as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
