Kepa or William, Are either of you watching or aware of Microsofts efforts with regard to SOAP, DIME, WS Referal and WS Routing? Do you see these efforts impacting this group?
http://msdn.microsoft.com/library/en-us/dn_voices_webservice/html/service01152002.asp http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-referral.asp http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp Regards, RB >>> "William J. Kammerer" <[EMAIL PROTECTED]> 02/14/02 11:32AM >>> I wrote on Friday, 01 February, 2002 in "Using a hybrid DNS:" I would dispense with using DNS sub-domains [to describe the trading partner capabilities]: can't the 52345.NAIC.HIPAA.NET record itself just point - with a URL - to an XML document which has all information for Acme [who is NAIC 52345]? 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. Can the DNS MX-type record (or whatever) point to an XML file - e.g., https://edi.anthem.com/myprofile.xml? Development of the XML schema can proceed without being hung up waiting for someone to implement the DNS "directory." Another advantage of using DNS to point to XML files is that once the MX-type record has been defined (I assume by the ISP for a small provider who doesn't manage his own mail server), that provider can maintain his own XML profile without always having to run off to his ISP for the most trivial of changes. And other directories, if they ever come about - like the National Provider Directory or UDDI, can also point to the same XML document. Every time Chris Feahr - the Everyman provider - adds a new transaction capability (like the 835 ERA) to his Javascript repertoire, I'd hate to see him have to struggle with his ISP in order to define a new DNS node - e.g., 004010X091.123456789.npi.hipaa.net. Rather, he would just update http://visiondatastandard.org/MyEDIStuff.XML using his favorite text editor or XML Spy. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Dick Brooks" < [EMAIL PROTECTED] > To: "Kepa Zubeldia" < [EMAIL PROTECTED] >; < [EMAIL PROTECTED] > Cc: < [EMAIL PROTECTED] > Sent: Thursday, 14 February, 2002 09:42 AM Subject: RE: auto-discovery of the "return path" (In the Kepa-DNS model) 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
