Kepa Zubeldia proposed a DNS structure for resolving EDI addresses: For example, ACME insurance could have a HIPAA address of ACME.HIPAA.NET and under that DNS server have other domains such as 837.ACME.HIPAA.NET, 270.ACME.HIPAA.NET, and 276.ACME.HIPAA.NET. Then, under the 837.ACME.HIPAA.NET DNS server there could be several MX records listing:
ACME.PAYERS.WEBMD.HIPAA.NET (20) and NDC.HIPAA.NET (20) and ACME.CLEARINGHOUSE-A.HIPAA.NET (75) and 2125551212.PHONE.HIPAA.NET (300) which would say that they can receive transactions directly over the telephone at 2125551212, or though three different clearinghouses. The best path is through either WEBMD or NDC, the next choice would be through clearinghouse "A" and the last choice would be sending direct transactions to ACME. I have put the "preference" factors in parenthesis for readability, but you get the picture. In fact, this could be used to represent more information in the MX records, such as an "IP port" or a "protocol" or even, stretching it a bit, something like xmodem.8005551212.phone.hipaa.net as a direct connection if we assign the "phone.hipaa.net" to be a magic token. I think I understand how this is supposed to work, but I want to make a couple suggestions. Assuming the system is used to take EDI identifiers and resolve addresses out of them, then the identifier itself should be used in the search hierarchy. Guessing that Acme Insurance is named simply "ACME" rather than "ACMEINS" is a job in itself. But if you start with Acme's NAIC code 52345 (as you would if all you were looking at was the ISA), it would be pretty tough to come up with "ACME" *or* "ACMEINS." How about the top level structure taking the form of something like 52345.NAIC.HIPAA.NET, instead? Next, I would dispense with using DNS sub-domains from then on: can't the 52345.NAIC.HIPAA.NET record itself just point - with a URL - to an XML document which has all information for Acme? That XML document - describing channels, preferences, certificates and anything else - could be resident anywhere: either at ACME Insurance or its Clearinghouse. An XML document would be, well, more eXtensible, and allow non-network people to maintain it. And besides, it seems DNS is not all it's cracked up to be, what with "disappearing" web sites waiting for DNS entries to propagate themselves through the network! At least the URL that 52345.NAIC.HIPAA.NET "points" to would be more stable. I suggest that the detailed document for Acme be in XML simply because that's sexy. And besides, Dick Brooks may figure a way we can hijack the ebXML Collaboration Protocol Profile (CPP) specification for doing everything we need in describing transport channels, protocols, certificates, or business processes (837 vs. 270). None of this should be construed to mean that I like any better the idea of the provider, or his agent, having to figure out a different transport channel based on the *type* of transaction. As I've said before, it would be better if all the provider's transactions could be placed through a single conduit matching the needs of the provider, and the payer (or its agent) would requeue them based on its needs. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
