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: [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




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 routing-request@wedi.org
containing the word "join" (sans the quotes) in the body.  Postings are
sent to the mailing list at routing@wedi.org.  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 routing@wedi.org 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.




More on the "Discovery" of Electronic Trading Partner Agreements.  Two
weeks ago we demonstrated how it was possible to locate trading partners
using Kepa's DNS "directory."  Kepa had set up a DNS node for me,
072930527.duns.hipaa.net, based on my D-U-N-S, containing an MX record
pointing to a "host" name.  When I first saw my "host" name come across
after doing the DNS lookup, it was one of those epiphanic experiences -
like when Bell told Watson on the first telephone call: "Mr. Watson--get
your arse over here--I want to see you."

But instead of using (or "mis-using") the DNS MX (Mail Server) record -
which can only point to a "host" - I asked if we could use some other
type of DNS record which would give us more flexibility in pointing to
an electronic Trading Partner Agreement.  Kepa suggested the TXT record,
a DNS record type which supports free-form text.  But rather than simply
making a TXT record which just included the URL of my Electronic Trading
Partner Agreement, I figured we had better plan in some extensibility -
so later on, if needed, date-time stamps could be inserted - and devised
a simple XML "document" using xlink to "point" to the e-TPA.  You can
find this "pointer" by using the Windows/DOS nslookup program:

C:\>nslookup -type=txt 072930527.duns.hipaa.net
Server:  resolver.qwest.net
Address:  205.171.3.65

Non-authoritative answer:
072930527.duns.hipaa.net        text =

        "<HIPAA xmlns:xlink="http://www.w3.org/1999/xlink"><TPA
xlink:href="http://novannet.com/MyEDIStuff.XML"/></HIPAA>"

072930527.duns.hipaa.net        nameserver = ns1.claredi.com
ns1.claredi.com internet address = 216.219.239.179

C:\>

The only real important thing in the retrieved text is the URL of my
e-TPA - http://novannet.com/MyEDIStuff.XML.  For right now, since we
don't have any idea of what our e-TPA will look like, the file at that
location on my Web server is just a copy of the TXT record itself.
Eventually we could either use an ebXML CPP or some XML schema of our
own design as the format of the WEDi/SNIP Electronic Trading Partner
Agreement.

There are important points illustrated by this exercise:

(1) Kepa's DNS "directory" technique is *one* way to find e-TPAs of your
trading partners based on their D-U-N-S (as in this example), NAIC
co-code, Tax ID No., HIN or whatever other type of IDs are allowed in
the ISA Receiver field.  Once you know the receiver's ID, it will be
possible to "discover" their Electronic Trading Partner Agreement (still
to be determined, but most likely an XML document).

(2) The "pointers" in the DNS "directory" themselves would not have to
change much, unless to update the time-stamps.  Though a third-party
(the "owner" of the particular HIPAA.NET node) has to maintain your TXT
"pointer," the e-TPA it "points" to resides on your own server.  You
have complete control over its security and maintenance, and do not have
to rely on a third-party to update it.  Time stamps in the DNS TXT
record "XML" document could be used to let trading partners know your
e-TPA has been modified without having to access your  server (i.e., to
retrieve a copy of the e-TPA to see if it has changed).  The e-TPA could
become inaccessible if your server is down - but then, most likely your
EDI "front-doors" would be unavailable, too!

(3) Kepa's DNS "directory" is distributed, by the very nature of the
Internet Domain Name Service.  Even if Kepa's servers go down, copies of
the "pointers" in the TXT records have already been automatically
propagated to other name servers throughout the system (e.g., I obtained
my "pointer" from Qwest's name servers, not Kepa's).

There are other means of "discovering" your Trading Partner's e-TPA,
including the ebXML Registry, at
https://www.oasis-open.org/committees/regrep/, and UDDI, at
http://www.uddi.org/.  Kepa's method has the advantage of, well....
working.  To be fair, the ebXML Registry and UDDI are much more
ambitious distributed directories which including general query
capabilities for which we have no use.  You already know your trading
partner's ID code which forms part of the HIPAA.NET DNS node - you're
not searching for (any) proctologists in the Columbus, Ohio metro area.

Does anyone want to volunteer their Java programming skills to build a
little utility to take the ID domain (e.g., DUNS, NAIC, EIN) and ID
number, and retrieve the electronic TPA as an XML file?  If Windows'
nslookup can do it, then I figure such a program can be written.   That
code will make a nice addition to the White Paper, err, ugh.. I mean, a
Working Document.

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