clarification on the DNS model
Ronald, Let me clarify something that may not have been properly expressed. One of the problems we are facing today, and will face more acutely tomorrow with the HIPAA PlanID, is how to identify the entry point for a plan ID. The entry point may not be the payer, but a PPO instead. Or we may not know who the payer is, and only know the PlanID. So trying to resolve the first phase of the DNS with a PlanID.PayerID.naic.hipaa.net sort of convention may be impossible. We probably don't know who the PayerID will be. That is why I believe we will need a double lookup, once to look up the DNS server based only on PlanID.naic.hipaa.net, and another to look up the entry point itself, by asking that DNS server. The first lookup could have a relatively static resolution, based on a central database that changes infrequently and points to the DNS servers, and the second lookup will probably benefit from the distributed maintenance due to its high volatility. In that second lookup, if the payer chooses to use something like your proposed PlanID.PayerID.naic.hipaa.net, so be it. But I suspect they will choose something more under their own control, like PlanID.Payer.com The other concept that I need to clarify is that of the relationship between the ISA and the transaction content. Or the lack thereof. When you say: "The biggest assumption this model seems to make is an ISA/IEA will only contain transactions destined for a single Transaction Receiver (PayerID)." I can see that I have not quite explained this right. The assumption here is that there is NO relationship between the ISA and the actual payers inside the transactions. There could be a relationship, and I have used the example of when the two are related, but most of the time there will be no relationship. For example, if I find that the payer in the claim is identified with PlanID:987654321, I would look for the DNS server for this plan by looking up 987654321.PlanID.hipaa.net. This would point to a DNS server that says (in the MX records) that I have a choice of three clearinghouses to get to this PlanID. Let's say that one of those clearinghouses is WebMD. This can be easily determined even before the transaction is translated into X12. At that point I would put the transaction in the WebMD "queue". Later in the day, I could gather all the claims in the WebMD queue and build an 837 transaction for WebMD that contains a lot of claims for a lot of different payers, all of which are pointing to WebMD as their clearinghouse. So, I create this 837 ready to send to WebMD. Then I lookup in the DNS to find what is the access point for WebMD and it gives me a telephone number or a web site or an FTP site through which I can reach WebMD. The trick here is that I have not made any assumptions about the association between the content of the transaction and the ISA being for the same delivery point. Essentially I am describing a spooling system, with address discovery before you queue the transactions into one of the queues, and not necessarily a tying between the spool queues and the physical devices. You could have multiple queues for the same device, as long as the device can handle it. If you were to tie the PayerID or PlanID from inside the transaction to the one in the ISA, you would force the entire industry to change what we are doing today, and would create havoc with clearinghouses and providers alike. I am NOT proposing anything of that sort. Echoing Bob Poiesz's comments, we need a system that will work in the future, but more importantly, we need a system that will work today. Today we send multiple payers into the same queue/clearinghouse. We need to continue to do this. We also need the capability to have more than one queue, so we have a choice. In any case, the ability to discover the delivery point(s) for any one health plan is the core of my proposal. And I propose to do so without a centralized database that would be almost impossible to manage, but rather give each payer the control over their own "domain of authority" for their own PlanIDs. I hope this helps. Kepa
Re: clarification on the DNS model
Kepa, Thank you for continuing to re-explain this with examples... the beauty of this proposal is finally sinking in for me. Am I correct in assuming that the practice we discussed earlier of having several primary payors (i.e., several PlanIDs) in a single 837 would not break this model? I suppose that anyone creating a multi-payor 837 would already have to know which clearinghouse to send it to and would, therefore, not need this address discovery process (?). -Chris At 03:22 PM 2/9/02 -0700, Kepa Zubeldia wrote: >Ronald, > >Let me clarify something that may not have been properly expressed. One of >the problems we are facing today, and will face more acutely tomorrow with >the HIPAA PlanID, is how to identify the entry point for a plan ID. The >entry point may not be the payer, but a PPO instead. Or we may not know >who the payer is, and only know the PlanID. So trying to resolve the >first phase of the DNS with a PlanID.PayerID.naic.hipaa.net sort of >convention may be impossible. We probably don't know who the PayerID will >be. That is why I believe we will need a double lookup, once to look up >the DNS server based only on PlanID.naic.hipaa.net, and another to look up >the entry point itself, by asking that DNS server. The first lookup could >have a relatively static resolution, based on a central database that >changes infrequently and points to the DNS servers, and the second lookup >will probably benefit from the distributed maintenance due to its high >volatility. In that second lookup, if the payer chooses to use something >like your proposed PlanID.PayerID.naic.hipaa.net, so be it. But I suspect >they will choose something more under their own control, like PlanID.Payer.com > >The other concept that I need to clarify is that of the relationship >between the ISA and the transaction content. Or the lack thereof. When >you say: "The biggest assumption this model seems to make is an ISA/IEA >will only contain transactions destined for a single Transaction Receiver >(PayerID)." I can see that I have not quite explained this right. > >The assumption here is that there is NO relationship between the ISA and >the actual payers inside the transactions. There could be a relationship, >and I have used the example of when the two are related, but most of the >time there will be no relationship. > >For example, if I find that the payer in the claim is identified with >PlanID:987654321, I would look for the DNS server for this plan by looking >up 987654321.PlanID.hipaa.net. This would point to a DNS server that says >(in the MX records) that I have a choice of three clearinghouses to get to >this PlanID. Let's say that one of those clearinghouses is WebMD. This >can be easily determined even before the transaction is translated into >X12. At that point I would put the transaction in the WebMD >"queue". Later in the day, I could gather all the claims in the WebMD >queue and build an 837 transaction for WebMD that contains a lot of claims >for a lot of different payers, all of which are pointing to WebMD as their >clearinghouse. > >So, I create this 837 ready to send to WebMD. Then I lookup in the DNS to >find what is the access point for WebMD and it gives me a telephone number >or a web site or an FTP site through which I can reach WebMD. > >The trick here is that I have not made any assumptions about the >association between the content of the transaction and the ISA being for >the same delivery point. > >Essentially I am describing a spooling system, with address discovery >before you queue the transactions into one of the queues, and not >necessarily a tying between the spool queues and the physical devices. You >could have multiple queues for the same device, as long as the device can >handle it. > >If you were to tie the PayerID or PlanID from inside the transaction to >the one in the ISA, you would force the entire industry to change what we >are doing today, and would create havoc with clearinghouses and providers >alike. I am NOT proposing anything of that sort. > >Echoing Bob Poiesz's comments, we need a system that will work in the >future, but more importantly, we need a system that will work today. Today >we send multiple payers into the same queue/clearinghouse. We need to >continue to do this. We also need the capability to have more than one >queue, so we have a choice. In any case, the ability to discover the >delivery point(s) for any one health plan is the core of my proposal. And >I propose to do so without a centralized database that would be almost >impossible to manage, but rather give each payer the control over their >own "domain of authority" for their own PlanIDs. > >I hope this helps. > >Kepa > Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
RE:Requirements Gathering
Rachel, I would be glad to begin working on a draft list of specific terms and definitions for this project. Can we start with Ron's proposed interchange sender/receiver definitions? >>INTERCHANGE(ISA) SENDER: Entity responsible for preparing the transaction sets (ST/SE) into functional groups (GS/GE) and interchange controls (ISA/IEA) for transmission to the INTERCHANGE RECEIVER and for resolving a functional acknowledgment (997) that contains errors regarding the interchange. >> >>INTERCHANGE RECEIVER: Entity responsible for processing the function group and transaction sets (GS/GE, ST/SE) within an interchange control (ISA/IEA) and sending a functional acknowledgment (997) back to the ISA SENDER.<< -Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
Re: Using a hybrid DNS
William, Thanks for your ongoing concern for us "little people (providers)", but the more I think about divorcing the payor/plan ID info in the transactions from the receiverID info in the ISA, the more I like it... because it embraces the models in use today in which there really is no relationship between these two addresses. If the industry is willing to adopt the distributed address directory model that Kepa is proposing, then the "little people" can either hound their office system vendors to include that capability... or the smart vendors will see the business opportunity and sell the address discovery process to the provider as a value-add... or the small provider can just shovel all of his claims to one clearinghouse and let the CH worry about routing them. Since the need to know where to send these interchanges is going to be so acute for the provider, I can't imagine a situation in which no one was willing to create a system that would do the address discovery for them. -Chris At 09:16 PM 2/8/02 -0500, William J. Kammerer wrote: >Ronald Bowron wrote "...based on the definition of the routing >objectives, the ability to communicate based on the ST/SE transaction >type was defined as out of scope, and that routing should be limited to >the ISA/IEA and possibly the GS/GE." > >Using the transaction set as one component to determine the destination >of an interchange was never defined out of scope. But *requiring* >anything other than what's available in the ISA to determine routing >would place a burden on providers new to the standard transactions - or >their agents (VANs). Altruistically, my concern is motivated solely by >the needs and capabilities of the "little" people (providers). > >Generally, anyone producing standard transactions is aware not only of >the ISA sender or receiver fields, but also stuff in the GS and the ST - >theoretically they could make decisions for routing, selecting the >appropriate node in Kepa's DNS scheme. But it might be asking too much >of their off-the-shelf practice management software to traverse Kepa's >DNS tree (or even to use a CPP type of arrangement). Instead, they (the >providers) should be able to dump all their interchanges into one >conduit and be assured their "stuff" will get there safely, securely and >reliably based solely on receiver ID. > >If that conduit were a VAN, wouldn't it be too much to expect the VAN to >burrow within each and every interchange, group and transaction set to >determine routing? It's not impossible, certainly. But, again, why >should the sender (or her agent) have to concern herself with each of >the variables present in the ISA, GS and ST (and possibly more, if you >consider real-time requests which are evident only by looking within the >transaction set) and figure it out on her own where to send the >interchange? Isn't the ISA receiver ID enough? She has already >specified the recipient's NAIC, Plan ID, or whatever, in the ISA. Once >it gets to the payer, I think it should be incumbent on him to figure >out how to internally route the interchange (or functional groups >within). > >This situation isn't directly analogous to Kepa's example of different >addresses for snail mail - Kaysville for inquiries and payments to >Montclair - as Kaysville and Monclair are probably separated by really >big mountains or deserts in the real world (I'm not that good at >geography, but I know things like that got in the way of the >California-bound settlers). But in the virtual Internet world, they >are separated by a few micro-seconds. The receiver knows best where to >route his incoming stuff so let him do it. Delegating the >"mailroom" function to the sender (usually the provider) is an >impediment to frictionless e-commerce and an extra cost providers can do >without. > >William J. Kammerer >Novannet, LLC. >+1 (614) 487-0320 > >- Original Message - >From: "Ronald Bowron" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Friday, 08 February, 2002 07:24 PM >Subject: Re: Using a hybrid DNS > > >Kepa, > >Thanks Kepa. I believe I understood this but have a much better >understanding now, and look forward to the day it is standardized. > >I can see how easy it would be for the NAIC (Payer ID + SubID) to >represent the Plan Codes. When they finally do develop Unique Plan >ID's, I would hope they keep this simple structure in mind and add the >support for alpha numeric(base 36, 0-Z - although this could cause >problems if bar coding were required) or at least a checksum digit . > >In using a NAIC method, I would suggest the DNS lookup format of >PlanID.PayerID.naic.hipaa.net. Payers could accept all Interchanges to >PayerID.naic.hipaa.net or specify which plans codes they accept allowing >the system to be more easily managed. This also fits the hierarchical >model better. > >The biggest assumption this model seems to make is an ISA/IEA will only >contain transactions des
Re: Using a hybrid DNS
Chris: I'm just a populist at heart! But I'm also a little confused! If you (a provider) have a standard claim transaction intended for a particular National plan ID, say 987654321, you would build a single 837 with the payer (or plan?) indicated in the NM1 within the 2010BB loop. You would not comingle claims for multiple payers or plans, like a CH might (as Bob Poiesz has illustrated). So, who else's ID - other than the payer's - would be in the ISA receiver field? There does seem to be a relationship when standard transactions go from provider to payer, unmolested, via a VAN or EDIINT software. I suppose if you've been told, via Kepa's "directory," that claims for PlanID 987654321 go to WebMD, WebMD might demand that their ID be in the ISA receiver field - but yet, they already know they're the receiver! In that case, it's almost irrelevant what's in the ISA receiver field - WebMD sounds like they're going to strip search the 837 anyway in order to combine your claims with those of other providers intended for whatever TPA or Payer handles PlanID 987654321. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 - Original Message - From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> Sent: Saturday, 09 February, 2002 07:46 PM Subject: Re: Using a hybrid DNS William, Thanks for your ongoing concern for us "little people (providers)", but the more I think about divorcing the payor/plan ID info in the transactions from the receiverID info in the ISA, the more I like it... because it embraces the models in use today in which there really is no relationship between these two addresses. If the industry is willing to adopt the distributed address directory model that Kepa is proposing, then the "little people" can either hound their office system vendors to include that capability... or the smart vendors will see the business opportunity and sell the address discovery process to the provider as a value-add...or the small provider can just shovel all of his claims to one clearinghouse and let the CH worry about routing them. Since the need to know where to send these interchanges is going to be so acute for the provider, I can't imagine a situation in which no one was willing to create a system that would do the address discovery for them. -Chris
RE: Requirements Gathering
Chris, Thanks. Go for it! As you may recall from one of my earliest messages to this list, I strongly suggested that this effort needed a glossary so that all of us can use terms that have the same semantic definition for all of us. Would you like to be the starter and keeper of this project glossary? Rachel -Original Message- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 09, 2002 5:42 PM To: [EMAIL PROTECTED] Subject: Re: Requirements Gathering Hi Rachel, I would be glad to begin working on a draft list of specific terms and definitions for this project. Can we start with Ron's proposed interchange sender/receiver definitions? >>INTERCHANGE(ISA) SENDER: Entity responsible for preparing the transaction sets (ST/SE) into functional groups (GS/GE) and interchange controls (ISA/IEA) for transmission to the INTERCHANGE RECEIVER and for resolving a functional acknowledgment (997) that contains errors regarding the interchange. >> >>INTERCHANGE RECEIVER: Entity responsible for processing the function group and transaction sets (GS/GE, ST/SE) within an interchange control (ISA/IEA) and sending a functional acknowledgment (997) back to the ISA SENDER.<< -Chris At 07:42 PM 2/8/02 -0600, you wrote: >Over the last several weeks there's been excellent discussion and >"brainstorming" taking place on this list. Now it's time to get more >focused, specifically on requirements determination. > >It seems that I've volunteered to lead the EDI Addressing & Identifiers >subgroup responsible for policy and requirements. Accordingly, I'd like to >begin the process of collecting requirements. However, I think that a good >approach to requirements gathering would be to begin the process of >describing the many different scenarios that will need to be addressed for >each of these two key activities: EDI Addressing and Identifiers. > >Towards that end I'd like to request submissions of various scenarios that >will need to be supported. Can we begin by using this format: > >For each scenario: >--specify whether it is an EDI Addressing or Identifier scenario >--identify the players (e.g., provider, clearinghouse, payer, TPA, PPO, >etc.) involved >--describe the scenario, e.g., which party initiates the activity, what >are the various parties, their roles, the sequencing of their involvement >--describe the outcome of a successful scenario > >After a reasonable period of time I'll try to put each of the scenarios >submitted into a formalized template/document so that the more detailed >effort of requirements determination can begin. > >Please start the subject of each message as follows so that I can group and >management each message: > >Scenario: EDI Addressing >or >Scenario: Identifiers > >Thanks, > >Rachel > >Rachel Foerster >Principal >Rachel Foerster & Associates, Ltd. >Professionals in EDI & Electronic Commerce >39432 North Avenue >Beach Park, IL 60099 >Phone: 847-872-8070 >Fax: 847-872-6860 >http:/www.rfa-edi.com Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
