As expected, my introductory e-mail to the OASIS ebXML Registry TC has elicited responses from no fewer than three ebXML Registry software vendors - all these guys are tripping over each other to be the first in line to help us out. I think name-dropping WEDI/SNIP really opens doors. Everybody wants to get in on the "Next Big Thing" - HIPAA: the best thing that ever happened to EDI.
Of course, the Joint WEDI/SNIP and AFEHCT ID & Routing group will be happy to work with any vendor on our pilot study for the registry. Say what?!! We haven't mentioned anything heretofore about pilot studies - it just popped into mind: every standards group needs to have self-perpetuating activities planned for the future!! As I said in my e-mail to the OASIS ebXML Registry TC, pretty much all we want to do is store "pointers" to participants' CPPs (which reside as XML files in their own servers), retrievable by one or more entity IDs. For example, a Big Payer may well choose to be identified by their NAIC company code. Providers, on the other hand, like hospitals, may prefer to name themselves by any of a HIN, a D-U-N-S or a Federal Tax ID. Likewise, a small practice may be identified solely by Tax ID, at least until the National Provider ID is available. Even if a small provider doesn't do standard HIPAA X12 transactions himself (but rather uses a Clearinghouse or Billing service), he would still have an entry in the Registry with a vestigial CPP (probably resident in the ebXML Registry itself) which points to his respective agent (e.g., via the ID of the clearinghouse or billing agent). When the National Plan ID does comes into play, we would have multiple levels of indirection in the retrieval: the plan ID would be used to retrieve a pointer to the payer or Third Party Administrator (TPA), which in turn would be used to access that entity's CPP for technical trading partner information. Implementing search by Plan ID might be more efficacious with the ebXML Registry rather than with Kepa's DNS directory. This should be a very simple use of the ebXML registry, and it allows us to get some experience in the best ways to identify partners. We need to get away from proprietary payer-assigned provider IDs in the context of standard transactions, so as to level the playing field between payers, providers and clearinghouses. The registry will also be a test-bed for experimenting with various means of authenticating partners (using X.509 certificates). It might be too much to expect Dick Brooks to do the liaisoning with both the OASIS ebXML Messaging and the Registry Technical Committees. Does anyone here want to volunteer to develop Registry use cases involving the discovery of WEDI/SNIP CPPs? It would be much more appropriate for a "real" health care person to take on this role: someone from either the payer, provider, or clearinghouse sectors needs to step up to the bar on this effort if it is to provide anything that will be acceptable to the user base and solve real problems. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
