Kepa, I've been thinking quite a bit about the discovery issue and was wondering if there is a trend toward standard naming conventions underway, which could provide an answer to "some" of the discovery issues in Healthcare. For example, it's common for companies to name their web sites www.whatever.com. For example if I go to any of the following sites, I'm virtually guaranteed to arrive at the "Internet Front Door" of each company: www.ibm.com www.anthem.com www.bcbsal.com www.bcbsnc.com www.uhc.com www.envoy.com www.ascensionhealth.com
If a standard naming convention were to spill over into "EDI" it's conceivable that companies might establish an EDI front door at: edi.ibm.com edi.anthem.com edi.bcbsal.com edi.bcbsnc.com edi.uhc.com edi.envoy.com edi.ascensionhealth.com Or more specifically, a HIPAA front door: hipaa.bcbsnc.com hipaa.uhc.com hipaa.envoy.com hipaa.bcbsnc.com Now provide the "missing pieces" of the URL, http://, https://, ftp:// and we know the protocol to use, e.g. https://edi.envoy.com/. Clearly, this is not a total solution because the "domain portion" has to be discovered. For example how did I know United Healthcare was uhc.com. So what's missing from this picture? All the nitty gritty details about how to conduct e-business with each of these companies. IMO, this is the real challenge; How to "automate" the trading partner setup process for such a large community. Perhaps this is the more important function to be performed by Kepa's "DNS repository concept". Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com <http://www.systrends.com> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 13, 2002 8:56 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: auto-discovery of the "return path" (In the Kepa-DNS model) Chris, The MX record points to the "mail" server. Actually, to a server that is listening for SMTP on Port 25, whether it is sendmail or otherwise. The invention would be to use the same concept but it could be a generic notion of EDI server that would be listening at the IP address specified in the MX record. At that address it could listen for EDI transfers in multiple ports: Port 25 for SMTP transfers (including EDIINT), port 443 for SSL-HTTP transfers, and other ports as appropriate. It does not have to be limited to SMTP on port 25. Kepa Christopher J. Feahr, OD wrote: > Kepa, > is the "EDI Server" concept one that is in standard usage or is that the > part we are proposing to "invent" here? If I understand the MX Record > concept correctly, it is essentially a routing table on the DNS server > that tells the world the address of a particular machine that is under > control of a particular internet domain (i.e., a mail server, a > web-server, an SSL server, FTP server, etc.)? If so, would the "EDI > Server" also contain something like the MX record... or would it just be > one of the things that the DNS server's MX record points to? > > Thanks, > Chris > > At 08:36 AM 2/13/02 -0700, Kepa Zubeldia wrote: > >> Chris, >> >> Nothing is "automatic", but a provider that designates a clearinghouse >> as its delivery point would also designate the clearinghouse as its >> DNS server. A provider that has its own "server" acting as its own >> delivery point, would have to point its DNS server to the EDI server >> acting as a delivery point. >> >> Same thing happens today with DNS and email. If I want to get my >> email to be hosted by my ISP for the domain "kepa.com" then my ISP >> will also host my DNS server and will point the MX record of the DNS >> server for kepa.com into the ISP's own mail server. If I want to have >> my own mail server, either my ISP hosts the DNS for kepa.com and >> points the MX record to my own mail server, or I host the DNS myself >> and point it to my own mail server. >> >> Since this infrastructure is already in place for MX records, we could >> as well use it for EDI also. >> >> Kepa >> >> >> Christopher J. Feahr, OD wrote: >> >>> Speaking of semantics, we should figure out a standard term for the >>> DNS model that Kepa has suggested. >>> Anyway, in that model, if a "small provider" (also needs a >>> definition!) is able to send a claim (or anything) directly to a >>> payor using the health plan's "smart EDI address"... will this >>> automatically mean that the payor will be able to discover the >>> address/route back to the provider for 271s, 824s, etc.? (I assume >>> that the 835 will require special handling in a provider-payor >>> agreement) >>> Does the provider's EDI address automatically get entered into the >>> "DNS table" in this proposed model? >>> -Chris >>> Christopher J. Feahr, OD >>> http://visiondatastandard.org >>> [EMAIL PROTECTED] >>> Cell/Pager: 707-529-2268 >> > > Christopher J. Feahr, OD > http://visiondatastandard.org > [EMAIL PROTECTED] > Cell/Pager: 707-529-2268
