National Identifiers, such as the NPI, the Plan ID and the Employer ID don't really have any direct bearing on our work. Having a unique domain of IDs to work with to identify providers (and their roles), payers and sponsors is obviously a boon to healthcare applications and operations. But as we have long discussed, a uniform means of identifying healthcare EDI participants is not mandatory for the success of our proposed Registry and CPP electronic partner profile.
As long as *some* unique ID is available for searching (e.g., NAIC co-code, DUNS, Tax ID, etc.) the Registry, CPP electronic partner profiles can be located. The CPP itself would indicate the ID qualifier and value to be used in the ISA for interchanges sent to the receiver, along with the technical EDI address (e.g., protocol, network address, etc.). In short, the existence or non-existence of the National Identifiers is irrelevant to our specifications; if any do become available, they merely serve as one more viable identifier domain. Our work is not dependent on any of the National Identifiers. Having said that, it would be advantageous to have the National Plan ID as part of the insurance member card; as shown in my slides illustrating the Healthcare CPP Registry, at http://www.novannet.com/wedi/WEDI%20Healthcare%20Registry.ppt, it would be a fairly simple process to go from the card to the plan and then to the CPP of a TPA or Insurance company. Barring the existence of the National Plan ID, other identifiers for the payer would have to be used as locators (having been found some way, if not printed on the card itself). Payer to payer EDI, as with the 269 COB payment verification transaction set, is not expected to pose any unique problems: either payer would have a CPP which could be located in the Registry, and used just as in the provider-payer (or provider-TPA, or Employer-Plan, or CH-CH) model. The CPP is independent of the role an entity plays: it merely identifies the transactions he supports, and the EDI addresses to which transactions can be sent. Further, the CPP can be used independently of any Registry. The CPP is merely a machine readable XML document which describes or locates an entity's technical trading partner information, such as its EDI addresses, X.509 certificates, supported transactions, ISA and GS requirements, and companion guide information, among other things. These are matters that any entity has to discuss with any of its partners, and having a consistent machine-readable format to hold this information will be an advantage in ramping up trading partner recruitment and configuring EDI translation software. At a minimum, the CPP can be rendered in a neat human readable manner on any browser, long before any automated software can handle it. Implementation of the CPP electronic partner profile is just the first step to complete Open-EDI and frictionless e-commerce in the Healthcare "e-marketplace." Even by itself, it is incredibly useful, introducing standardization in trading partner setup and EDI enrollment. There is no reason to think we couldn't have a workable schema for CPP electronic partner profiles before the end of the year, depending on how hard we work. The Registry itself is a convenience: it is not critical to the CPP electronic partner profile. But once we have a registry, we'll wonder how we ever did without it! The Registry will allow you to share your CPP electronic partner profiles, without your partners' having to track you down manually. Though the registry involves a few more variables than building the CPP, we could have a workable prototype in short order with the assistance of NIST. Its use would be voluntary, but would there be any good reasons not to use it to point to your own CPP if it were available? It would save you the hassle of answering individual calls asking how to send transactions to you. Or "where is your X.509 certificate for encryption?" Or "what do you expect in the ISA?" And questions of that ilk. Though the CPP and the Registry specifications are a little more ambitious than the original modest goal (devising EDI Addresses to establishing connectivity) we set out for ourselves last February, I don't think there's much here that is Buck Rogers pulp fiction. Don't get hung up on the Open-EDI business quite yet. The CPP and Registry will be incredibly useful whether or not Open-EDI comes to pass. But nevertheless, I happen to believe that HIPAA in effect mandates Open-EDI, and only an automated infrastructure including the CPP and the Registry will make it possible for payers to conform to the spirit of the law. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, 31 May, 2002 09:22 AM Subject: RE: TA1 responding to non-participating health care providers In my opinion, we have to separate two things here. There is today - and the desired future. Today, an open door can not work. There ARE security issues and connectivity issues and identification issues and contract issues and validation issues and - well, you get the point. We can not ignore those or just make them go away. But, there must also be a vision for the future. I have had that vision for years, and shared it here. But, that IS very much a future vision today. We should be able to use the internet for open healthcare EDI. But that requires security and non-repudiation solutions and databases that provide identification and routing and validation and connectivity information. We do not have those today. This is not a simple situation. The problem that I see with the current discussion is that we are not actively recognizing that we have a today and a future. The talk often sounds like one side saying "The future is here, accept it" and the other side saying "I am not ready for it". As I recall from the beginning, the focus was on trying to establish a direction for the future vision and to facilitate the move to that future, not to impose the future. And, this group's focus is on only part of the total problem. I guess what I would like to see is a general tone of "This is were we should try to go". We could even identify the other issues or problem that must be solved before we can even go there. The interoperability work is part of that. The national identifiers is part. There will be a need for identifiers for other entities not specifically ID'd under HIPAA. And this will get even more complicated - I foresee a need for increasing payer to payer EDI. I don't recall any discussion about that dimension. Greg is right about healthcare today. Mimi is right about what healthcare needs to become at some tomorrow. The transition will be a bear, and will not happen overnight. I am hoping that this group can describe the destination, and maybe start to build the road map. I guess that's enough preaching for today. Maybe I'll see some of you next week at the X12 meeting. Bob
