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
