Mere existence of CPPs pointed to by the Healthcare CPP Registry tends to lend credence to them. Therefore, front-door security (perhaps for accessing, but certainly for contributing to the Registry) is extremely important, and should be bullet-proof - it's much more than a screen to keep the flies out! Security often seems to be treated by Registry affectionados as an after-thought, probably because it is such an intractable problem. I'm hesitant to say there'd be a Registry unless security is well-thought out.
Without first-hand knowledge of who is sharing a CPP with you, you're depending on the Registry security infrastructure to ensure the integrity of any data contents you obtain from the registry. For example, if I ask the Registry for the CPP of the Insurance company whose NAIC is 60054, I want to have assurance that it was indeed Aetna who created the CPP I get back! Up to this point I've been loathe to state the truth, lest folks be scared away from the whole concept of a registry: security (based on interoperable PKIs) is more than 50% of the Registry problem!! Again, we have two technologies on our platter: the CPP itself, which can be designed in the near-term, and then the Registry. The CPP electronic partner profile can be distributed "out-of-band" without the use of an automated secure Registry. If Mimi Hart qua provider and Bruce LeGrand qua payer decide they want to exchange HIPAA standard transactions, it will be a big time-saver if either can point the other to his own CPP. Bruce would probably have had to document in any case things like 1) what transactions he supports (all, in the case of a big payer), 2) where the companion guides reside, 3) what transactions go where, 4) his EDI addresses, and 5) how to obtain his X.590 certificates which senders will use to encrypt data to him over the Internet. The CPP will provide a consistent means of documenting this stuff - providing, in effect, a template to make sure we all do it somewhat the same way. This saves Mimi time, in that she only has to get used to one format for this commonly shared information - she doesn't have to wade through each payer's notion of documentation for the same kind of stuff. It works both ways: Bruce, by reading Mimi's CPP, will immediately know which transactions she supports; there's no need for Mimi to fill out that kind of information on some enrollment form - it's already available in the CPP she gives to Bruce. Note that there are fewer issues involved with certificates when CPPs are manually exchanged. Since Bruce himself told Mimi where to find his certificates - via the CPP - they can be self-signed and Mimi can automatically trust them. We have no problem with interoperable PKIs and incompatibilities of CA-issued certificates. Mimi can safely assume no scoundrel will intercept her claims because it was Bruce himself (via his CPP) who told her where to send claims and how to encrypt them. Even though Mimi might be receiving all her inbound data over one Internet EDI address, she can be assured that 835s purporting to come from Bruce are really his by checking the digital signature against the public key in the certificate Bruce gave her. Assuming Mimi trusts Bruce (that he really represents Big Payer), and Bruce trusts Mimi (in that she really represents Big Hospital), manual exchange of CPPs (or more likely, their URL pointers) will work very well. All this stuff works equally well if Mimi's dealing with a payer who has chosen to use a clearinghouse - it's just more indirect: e.g., Mimi may have to chase down the CPP of the payer's Clearinghouse to obtain its (latest) EDI addresses and the CH's certificates. Eventually - some time way post H-day - Mimi's translator and communications software may automatically configure themselves off of the CPP. But that's not necessary today in order to reap the benefits of a standardized means of exchanging partner profiles: our freebie XSLT style-sheet can render the CPP in a human-readable form. So far this use of the CPP doesn't preclude Bruce or any other payer from "vetting" his partners. Mimi would have had no idea where to send claims to Bruce, unless he "invites" her by sharing his CPP. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: "Bruce T LeGrand" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, 17 July, 2002 05:06 PM Subject: Re: first cut on "overview" document Bruce, It's quite possible that I'm being naive here... but what sorts of risks do you foresee if we make it very easy for someone to "register" their business in the Healthcare CPP Registry or to search it for the URL of another's CPP? If they had no legitimate reason to set up an EDI relationship... or the other party would not agree to it... then I'm not sure that I see a problem allowing them to conduct the search... maybe it should be configured to only return one record at a time to thwart would-be spammers. If an individual's CPP happens to contain sensitive information, the owner will be free to apply additional security to the CPP document itself. Same would seem to apply to some "knucklehead" listing himself in the registry. If none of the other listees will ever want to do EDI with him, then his registry record will sit there... wasting a little registry disk space... until it is removed by some "cleaning" process. Are you concerned about someone damaging the registry with "hacker" type activities? regards, Chris ----- Original Message ----- From: "Bruce T LeGrand" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 17 July, 2002 02:22 PM Subject: Re: first cut on "overview" document Don't make access to this too tantalizing. A simple screen is as good as no screen. A complex one is a challenge. Let due diligence and the TPA process curry out the flies. ------------------( Forwarded letter 1 follows )-------------------- Date: Wed, 17 Jul 2002 10:56:06 -0700 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] From: OD.ChristopherJ.Feahr[chris]@optiserv.com.comp Sender: [EMAIL PROTECTED] Subject: Re: first cut on "overview" document Mimi, My concept of "enrollment" as it applies to this project (although, a different word might be more effective in communicating this) is along the lines of what William has described: simply a mechanism for getting oneself "listed" in the registry AND some mechanism for keeping people out of the registry if there is no reasonable likelihood that they would ever have a legitimate reason to exchange EDI messages with someone who IS in the registry. So I would also agree with what I think William is saying that the security does not have to be ironclad in this regard. We do need to "clear" a certain group of businesses for easy access to the registry, but the worst case of having people listed who don't belong there is wasted hard drive space. The ability to look up someone's CPP doesn't seem that dangerous either because the potential partner will still have some "due diligence" to complete before the messaging can commence. So I see "enrollment" policy as essentially a screen-door to keep to flies out! Regards, Chris 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.
