OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [regrep] "Discovery" of WEDi/SNIP CPPs

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.

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

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

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

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