[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep] "Discovery" of WEDi/SNIP CPPs
William, Thank you for your note and your interest in the work of the Registry Technical Committee. We look forward to receiving requirements from your group, and definitions of clear use cases for the Registry. We would like to invite you to collaborate with us, and participate in our work as you feel appropriate for your team's activities. Sincerely, Kathryn Breininger ebXML Registry TC -----Original Message----- From: William J. Kammerer [mailto:wkammerer@novannet.com] Sent: Wednesday, March 20, 2002 6:13 PM To: ebXML Registry TC Subject: [regrep] "Discovery" of WEDi/SNIP CPPs I'm writing on behalf of the joint AFEHCT and WEDI/SNIP ID & Routing Group, where we're developing recommendations for the "auto-discovery" of Healthcare business partners (e.g., providers and payers) and their CPPs. WEDI/SNIP, at http://snip.wedi.org/, and AFEHCT, at http://www.afehct.org/, are voluntary industry forums instrumental in U.S. Healthcare EDI, specifically the implementation of the HIPAA standard EDI transactions. The attached e-mail, "ID & Routing Special Interest Group Update," gives some information on our particular group. Enacted in August 1996, the Health Insurance Portability and Accountability Act (HIPAA) is a U.S. federal law which is intended to improve the availability and portability of health coverage and to reduce the costs and administrative burdens of healthcare through the use of standardized Electronic Data Interchange (EDI). Toward that end, the legislation requires payers, clearinghouses and providers to standardize electronic transactions in a confidential and secure environment within two years following the publication of the final rules. In summary, pretty much all the thousands of health care insurance companies and large providers (such as hospitals) are under the gun to meet an October 2003 deadline for being able to do the "business" side of health care using ANSI ASC X12 EDI. This includes supporting electronic Claims, Claims Status, Payments, Eligibility Benefit inquiries, and Service Reviews. HIPAA EDI is the "Y2K problem" of the U.S. health care industry (though its implementation deadline has now been extended twice!). Further down the road, we are going to try to devise a test implementation between volunteer WEDI organizations to examine the efficacy of the WEDI/SNIP recommendations, which would rely on some type of registry for locating trading partners. I took a look at UDDI - at http://www.uddi.org/ - for its applicability to Healthcare HIPAA EDI, specifically for the automated discovery of business partners' CPPs (electronic "Trading Partner Agreements"). Though UDDI remains a possibility for discovering business partners' technical capabilities, its security (or lack thereof) makes it somewhat problematical. Anyway, I rather want to encourage as much movement as possible to the ebXML standards in support of HIPAA EDI - and the ebXML CPP and Registry could have a role here. We want to have a centrally managed registry for integrity - at least until a PKI is set up. I have already presented our plans to one particular ebXML Registry software vendor. and I'm hoping to get this vendor to manage an ebXML registry on their servers for running a pilot study. We have not completed our Registry requirements yet, but probably it's safe to say all requests for adding or modifying entities' registry information would come to a central point via e-mail (probably one of our volunteer companies), who would then vet the request and add the entry to the ebXML Registry. Anyone would be able to search the registry by partner ID - DUNS, NAIC, HCFA Carrier code, FEIN, etc. There's a limited set of ID domains that are used in Healthcare. Validation of IDs and submitted information would be relatively informal; later, we'll get fancy with X.509 certificates to authenticate requestors. We do, by the way, have an internal proposal to build a DNS directory for locating CPPs at the providers' or payers' sites; see the attached e-mail entitled "Electronic Trading Partner Agreement Discovery," which gives some notion how it would work. Our recommendations will probably not use too many of the capabilities of the OASIS ebXML Registry. All we would expect is some gizmo to allow a healthcare partner to say "I want the technical trading requirements for NAIC 51477," expecting to get back the URL pointing to Acme Insurance Company's CPP. Or they might give it the Tax ID number (FEIN) 55-2667772, and it would return the URL for St. Elmo Hospital's CPP. It's that simple. We'd be lucky to get a couple dozen WEDI/SNIP volunteers to donate their Trading Partner information that we could make CPPs from, which gives you an idea how much load this "demo" would take. Any one party can have multiple IDs from the same or different domains (e.g., multiple NAICs and DUNS might apply to the same party, "pointing" to the same ebXML CPP resident on the party's own machine). The CPP will usually, if not always, reside on the owner's machine, though we could allow for it being stored in the registry, also. Anyone would be allowed to retrieve CPPs based on ID domain and ID. Browsing would be completely optional; e.g., looking for all providers in Ohio who have a certain taxonomy code (e.g., "I'm a proctologist") might be an interesting thing to do, but not necessary: the payer already knows the provider's preferred ID, and vice versa. The taxonomy code would be in the CPP (or extensions), but could be "elevated" to the registry so searches could be done on it if we later decide to support browsing. Frankly, though, there's no real need for demographic information in the Registry itself - searching would be on an alphanumeric ID solely to retrieve the XML CPP resident at the party's own site. We have already approached the OASIS ebXML CPP/A TC suggesting that we may be presenting WEDI/SNIP requirements for the CPP/A V3 spec later down the road, and received a positive reception; see "WEDi/SNIP Electronic Trading Partner Agreements for HIPAA," at http://lists.oasis-open.org/archives/ebxml-cppa/200203/msg00003.html. This note is simply informatory to let your Technical Committee know that we exist and are watching your work! Hopefully, the OASIS ebXML Registry TC will likewise consider working with us in the joint AFEHCT and WEDI/SNIP ID & Routing project. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC