There is a definite situation with routing. Not necessarily a "problem" ... but those in the insurance industry who are having to jump in with both feet on the EDI stnd txn are just now coming out of mapping and into ... "How do we get the claim to the receiver?"
They have been so focused on the data elements and the gaps ... that the communications layer is now being discussed and defined within organizations. But since this also has "legal" tied to it via the TPA...the progress is slow at best. So, in my reading of this discussion I can see both points here. There definitely cannot be a "disconnect" between the routing and security. But, until the industry understands routing and addressing in EDI, security is not the priority. One lesson at a time. I agree with Bob that until the certificate, encryption, etc. are more fully defined, we must continue on the current security measures that current EDI users employ. The same logic as encryption can be said for ID Standardization. Until the HIPAA defined identifiers are final, another id must be found. I think that when HIPAA IDs are final that we "could" have central "phone book" for all IDs and their addresses. Security measures would still be in place and would have to ensure that a TPA exists before the transaction progresses any father into the system. But, until that happens, its just another "suggestion". Ruth Tucci-Kaufhold UNISYS Corporation 4050 Innslake Drive Suite 202 Glen Allen, VA 23060 (804) 346-1138 (804) 935-1647 (fax) N246-1138 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 2:32 PM To: [EMAIL PROTECTED] Cc: WEDi/SNIP ID & Routing Subject: Re: Whose name is it, anyway? 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: 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
