RE: Using a hybrid DNS

Kepa, At the Seattle ad hoc discussion Jim Moynihan also brought up an issue re identifiers - and that is that for many payers a provider may be associated to many different plans (planID) and today, such a payer assigns the provider a different provider ID for each plan. Thus, the provider must

RE: Requirements Gathering - Information Flows

Chris and Bruce, I would recommend that we at least get working definitions for these terms agreed to for purposes of advancing the work of this Work Group. They can they be added to the WEDi Glossary as needed, etc. Rachel -Original Message- From: Christopher J. Feahr, OD [mailto:[EMAI

Draft Notes from the Seattle X12 Identifiers & EDI Addressing Discussion

Zon Owen has graciously provided notes from the X12N/TG3/WG2 Transaction Coord. & Modeling/Healthcare Modeling Information Forum in Seattle last Tuesday, 02/05, where we discussed IDs and Routing. Zon said that the notes had been derived from his personal meeting preparation notes, from the Sign-

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

RE: auto-discovery of the "return path" (In the Kepa-DNS model)

Chris, Rather than "naming" a DNS model as you suggest below, I would suggest that we adopt the UN/CEFACT Unified Modeling Methodology and develop the appropriate use cases and scenarios in a more rigorous and disciplined manner. Actually, my proposed approach to requirements developed is based o

Re: naming the entity's "inbox"

I'm going to take a stab at answering my own question: Could we define "EDI Server" to be the "front door" or "inbox" for each entity generating transactions? Not sure where we would actually put "EDI Server Name" for the doctor who wants to receive messeges in this EDI Server, but who uses a

Re: auto-discovery of the "return path" (In the Kepa-DNS model)

Kepa has said nothing is "automatic." But there might be an exception with the simplest case of e-mail'ed transactions, where the recipient can discern the return-path for acknowledgements and responses. We do it all the time with ordinary e-mail: the first time I ever got an e-mail - totally u

Re: auto-discovery of the "return path" (In the Kepa-DNS model)

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 con

RE: Requirements Gathering - Information Flows

Bruce, I dont think any of the terms I'm proposing to define for this paper are in the existing WEDI glossary, but if they are, I agree that we should adhere to the established definition. We may want to propose adding out new terms to the WEDI glossary when we are finished, but in either case

RE: Requirements Gathering - Information Flows

Bruce, I would certainly not want to create another glossary if a WEDi glossy exists. Perhaps we just need to add entries, etc. Chris' assumption about my mission/intent ("...it was more a desire to nail down consistent semantics within the context of "addressing and routing" discussion...") is

RE: Requirements Gathering - Information Flows

Chris -- I would suggest approval for additional or supplemental glossaries be obtained before we expend a lot of effort to build and reference or use one in conjunction with a Routing white paper. I know the Exec and/or the Steering Committee addressed this issue before and we decided (among o

Re: auto-discovery of the "return path" (In the Kepa-DNS model)

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

auto-discovery of the "return path" (In the Kepa-DNS model)

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 auto

naming the entity's "inbox"

Ok, now I recall what I was thinking with "Transport Agent "... this would essentially be the identification of the entity functioning as the Interchange Receiver's "front door"... analogous to my "incoming mail server" for email. Everyone will have to designate one or more "front doors" or "