The problem is health plan/payer liability for credentialing a provider who is involved in a malpractice controversy - it's been a huge barrier to any rationalization of the credentialing process and would spill over to "credentialing" e-commerce id as well if fraud were a possibility. This has been explored in other venues and the only cure that's come up so far is national legislation that would remove some of the liability.
-----Original Message----- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 27, 2002 3:58 PM To: William J. Kammerer; [EMAIL PROTECTED] Subject: Re: The "Mao Zedong" PKI Model William, Thank you... this is the most lucid and understandable explanation I have read on this subject! It would seem that large payors are the ideal Certificate Authorities (CA) for providers in the context of not only the CPP registry, but of claims and payments. The due diligence undertaken by larger payors in their "provider credentialing" processes is legendary. This would seem to make them more trusted (to vouch for identity of providers in the context of the health care industry) than provider professional associations, who would have no other business purpose for being so thorough. Since payors have to perform this credentialing task anyway... and since they would themselves benefit from "certified" identity on claims, I would think that the providers could be given certificates for little or no cost. In fact, if all payors could agree on a universal (small) set of attributes they needed "certified" (e.g., some want to confirm malpractice liability coverage, levels of licensure, etc.) then one payor like CMS could perform this credentialing operation very efficiently for all payors. CMS would seem to be in a good position to certify the identities of payors, too. There would be ongoing administration, of course, and the more attributes that are certified, the more frequently the certificates will expire and need to be recredentialed. But this model would not expose anyone's "customer list", as it would if each payor (or CH, VAN, etc.) were to only certify his or her own customers. Does anyone know if CMS is contemplating this role in connection with the nat. Provider ID? -Chris >There a number of other serious problems with the trusted third-party CA >model. But you can read about them yourself in the available PKI >literature. I especially recommend Stephen Kent's "How Many >Certification Authorities are Enough?" at >http://csrc.ncsl.nist.gov/ecforum/comments/MILCOM_paper.doc. Pay >special attention to Kent's "Mao Zedong" PKI Model, which just might >lead to an economical and safe solution for identity and trust in >Healthcare. > >William J. Kammerer >Novannet, LLC. >Columbus, US-OH 43221-3859 >+1 (614) 487-0320 > > > >discussions on this listserv therefore represent the views of the individual >participants, and do not necessarily represent the views of the WEDI Board of >Directors nor WEDI SNIP. If you wish to receive an official opinion, post >your question to the WEDI SNIP Issues Database at >http://snip.wedi.org/tracking/. >Posting of advertisements or other commercial use of this listserv is >specifically prohibited. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited. discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.