Re: Whose name is it, anyway?

[Ronald Bowron]

Bob,   I agree that security will need to be addressed, but it doesn't seem to be the focus of the WHERE & HOW To identify the proper routing requirements for a transaction/document.   It's true that many of the larger players have their act together, that's why almost 90% of Institutional claims are currently electronic.  But, as the smaller plans come online,  will the status quo scale still support the goal of full EDI (98% utilization) within the Healthcare Industry?    Assuming the regulations properly identified the stakeholders on the payor side:   Large Commercial Plans: 250 Small Commercials: 400 BCBS:  48 TPA: 750 HMO/PPO:  1630 Self-Admin:  50,000 Other Employer:  2,550,000   and that over the next 2-7 years Plan Administration and Adjudication systems as well as Practice Mgt applications will more easily support the integration of HIPAA transactions, we may see a significant growth in the number point-to-point interface requirements or at least a significant growth in the overall routing of data to the appropriate destination.   It's possible that the management will get out of control as more plans and providers implement electronic exchange.   If we believe that scaling is there, then your right, we don't have a routing issue.   But, going from about 3000(guess) active payers and plans to possibly over 10,000(another guess) is quite a leap, what happens if it approaches 100,000.  To achieve 98% EDI in healthcare, I'm curious how many of the 2.5M other employer plans will need to be on-line.    What's at issue is WHERE will Providers turn to know HOW to send the electronic claim for a Large Self-Insured(or any plan) that just last month started accepting transactions through a Clearinghouse that the provider cannot directly connect.  How do competing clearinghouses address the issues of sharing trading partner routing information?   Let's assume (hope and pray) most of those in the Self-Admin and Other Employer categories chose to support clearinghouse connectivity even if it's web based.  Otherwise, this could get very messy in terms of providers managing routing.   I also agree that ZZ identifiers in the ISA shouldn't be eliminated, but I do support the concept of using them as a last resort and not used when other standard values will suffice. For an organization to take the position that ZZ is used more often than a standard code, they are violating the intent of standardization (unless the values associated with the ZZ code is under review for standardization, i.e. new standard identifier).  The only other situation is when the Sender ID is used with Security Information for real-time processing and routing or similar access controls.   Ron Bowron >>> <[EMAIL PROTECTED]> 01/23/02 01:31PM >>> William, Well, we are definitely at a crossroads. I strongly disagree with your assertion that use of ZZ and proprietary IDs could be construed as adversley impacting and therefore non-compliant. I understand fully your intent and where you are going. I disagree strongly with that direction and your insistance on separating the security aspects from the ISA issues. To me, that is doing the industry a disservice. You are moving to 'solve' a problem by ignoring another part of it. The supply side of health care is running quite differently than the 'insurance' side. VANs, drop boxes etc are a strong part of the supply side. Not of the insurance side. The insurance side is predominantly point to point. You may want to change things, but that takes a lot of time, and to do that you must address the full picture. And the security issues are an inherent part of that picture. Routing is NOT an issue today. We receive millions of claims per month from providers, billing services and clearinghouses. At last check, we have been receiving over 600,000 claims per month in X12 format. So do lots of others. The routing is there. Under HIPAA, it will still be there, and will be handled point to point. If you want to work on standardization of the ISA, I suggest that the ISSUE behind standardization is not routing, it is minimizing the number of IDs that must be maintained by the trading partners. And that issue can not be resolved without including the security issue. If you were to be highly successful and got the entire industry to move to a specific ID type for the ISA for each type of trading partner, you would STILL have a proliferation of IDs and passwords that were trading partner specific for access control and security. Someday, we may have good certificate solutions and encryption and Internet transport that will point to a total solution. Then a DNS or common directory will make security, routing and identification childsplay. People will wonder why this was such a probelm. It's just not here yet. In my opinion, the best bet is trying to move toward that future. But, as I said, we are obviously on different poles when it comes to defining the problem to be solved. Good luck. Bob "William J. Kammerer" To: "WEDi/SNIP ID & Routing" < [EMAIL PROTECTED] > <wkammerer@nov cc: annet.com> Subject: Re: Whose name is it, anyway? 01/23/2002 01:41 PM Bob: We are attempting to develop recommendations to the Healthcare industry for Trading partner identification and transaction routing. In order to fulfill the spirit of the HIPAA law, it must be possible for entities willing to use the standard transactions to have a somewhat predictable (read: standardized) means of getting their standard transactions to the payers. Everyone knows their own name(s). I even know my own D-U-N-S and FEIN. Providers probably know theirs, in addition to their HIN, and eventually their NPI. Payers know theirs, which might include their NAIC. My D-U-N-S should be the same, regardless which intermediaries I choose to use. A payer's NAIC, if he prefers to use it, should be the same regardless of the intermediaries the provider uses. Since these IDs have already been assigned, and are globally unique within their respective domains, why not use them? - at least until the globally unique National Payer and Plan IDs are available. And by all means, the "ZZ" should be banished: there should be no "mutually defined" in standards! IDs can't be used for authentication: there's nothing secret about them. You can easily find my D-U-N-S, even if I didn't give it to you. And I can easily find out what your NAIC is, even if you didn't give it to me. Likewise with HINs and eventually, National Payer and Plan IDs. Since IDs are easy to discover (even lacking a central database), they make ideal EDI addresses - but lousy passwords! Actually you shouldn't even have to "discover" them - the provider should be able to find them on the back of the patient's insurance card. Given the payer's ID, it should be possible for a provider, who's willing to cobble together a standard transaction, to get it on its way to the payer in the least confusing way possible. Anything less might be construed as a roadblock in the way of Administrative Simplification. You admit that you "...have a very non-standard situation in the ISA at this time, with the possibility of providers needing to identify themselves in different ways to each receiver." Standards are needed only for interoperability. Undoubtedly, your clearinghouse service is a well-oiled machine which works well for your customers, who are already seamlessly engaged in Healthcare electronic commerce. It probably matters little what we come up with here - your paying providers and payers are already electronically enabled, and they will happily accommodate themselves to whatever idiosyncrasies you mandate for the ISA. But to require a provider new to electronic transactions to munge the ISA, using IDs other than the sender's and receiver's own, might be construed as adversely affecting the provider as surely as charging fees for the privilege of submitting a claim or eligibility request. Once this door is opened, then payers might very well use other tactics like requiring the submission of standard transactions on diskette, or enforcing weird or obsolete protocols like X.400 or BiSynch, if the (payer's) preferred VAN or Clearinghouse is not contracted with. William J. Kammerer Novannet, LLC. ----- Original Message ----- From: < [EMAIL PROTECTED] > To: < [EMAIL PROTECTED] > Cc: < [EMAIL PROTECTED] > Sent: Wednesday, 23 January, 2002 09:33 AM Subject: Re: Whose name is it, anyway? William, While I certainly can (and personally advocate) the use of the security information in the ISA, that is not necessary for my point. Security is definitely part of this discussion. By your suggestion of keeping it separate, you establish an additional level to the ID issue/problem. We have for the claim:o We are attempting to develop re level 1 - provider submitting the claim level 2 - sender transporting the claim (ISA) level 3 - ID & password allowing access for submission of the claim What I believe we all need to do as business functions is: 1 - validate/authenticate sender (ID and password). 2 - validate authority of sender to represent/submit for the provider. To do that I only need two levels. While I admit that we have a very non-standard situatiobn in the ISA at this time, with the possibility of providers needing to identify themselves in different ways to each receiver, I am concerned that our attempt to 'solve' this for the industry is only complicating things. Unless we include levels 2 and 3 in our discussions, we will separate them and only succeed in 'moving' the problem to a new level (3). Then the provider/submitter will need to maintain their provider identifiers, their ISA Id, and a separate (receiver specific) access ID and password. The validation process for the receiver is also complicated by an additional layer. If we include security aspects in our discussion we reduce to provider ID and ISA/access ID and password (at least possibly). Bob