Ronald Bowron wrote: "If we could define the methodology for verifying the identity of a CE as part of the TPA process, then the TPA may be able to be automated....Would a notary model like Thawte (www.thawte.com) is using for certificates be acceptable, or overly complicated?"
Ronald: Obviously we will have to consider authentication as part of the Electronic Trading Partner Agreement process; like I said earlier, the last thing we would want to see is some hacker pretending to be Highmark by commandeering Kepa's DNS node 54771.NAIC.HIPAA.NET, where every provider relying on the DNS "directory" wanting to send claims to Highmark could have them intercepted by the hacker - if a Public Key Infrastructure (PKI) is not in place! Only the "owner" of the DNS node should be able to authorize changing the DNS node, and the Electronic TPA to which it points must be authenticated with a digital signature so trading partners can rely on the veracity of its contents. Electronic Trading Partner Agreements can be digitally "signed," and likewise, requests themselves to create or modify the DNS pointer to an electronic TPA can be signed. The ebXML initiative has looked at quite a few of the security aspects of maintaining a reliable Registry and Repository (for containing CPPs - the ebXML version of an Electronic Trading Partner Agreement). See https://www.oasis-open.org/committees/regrep/. Frankly, I think Kepa's DNS "directory" scheme is considerably less bloated than ebXML's effort, and can be implemented today within the HIPAA community. Having said that, maybe it's still worthwhile to look at the ebXML RegRep to see if there's something we can use or learn from. Digital signatures require digital IDs or certificates which have themselves been signed by a trusted third party - a "Certificate Authority," or CA. Ronald Bowron pointed us last Friday to an example of such a CA, Verisign, who was collaborating with the AMA to certify providers' digital certificates. Presumably, the AMA is the expert in identifying doctors, so this certificate authorization model makes sense on the surface. The Thawte notary model that Ronald asked about has the same weaknesses that any certification service has which is based on in-person presentation of credentials: those credentials are easily counterfeited. For example, the Thawte notaries rely on in-person presentation of a driver's license. I guess it kind of gives you some low-level assurance that an e-mail persona is possibly someone named on the driver's license - and that may be good enough in most cases. You have to ascertain the level of risk you're willing to bear relying on certificates backed by state-issued drivers licenses. The Verisign EDI Digital certificates go a little further, in that Verisign vets the submitted information, such as company name, against Dun & Bradstreet reports and kind of makes sure the applicant really is with the organization he purports to be with. This service costs nearly $1000. Is that good enough for a payer to rely on for validating the identity of a provider submitting claims? Maybe yes, when combined with procedures where checks are mailed only to the address on file for participating providers, or to the subscriber for out-of-network claims. In any event, the methodology - however imperfect - already exists for "verifying the identity of a CE as part of the TPA process." Our proposed system might be able to rely on CA-issued certificates which contain the entity identifiers being authenticated; I think it is out of scope for our group to worry about how those entities are authenticated (by the CA) in the first place. CA-issued certificates should be sufficient for automating the TPA process. The process for obtaining a certificate is not entirely onerous on an entity, especially considering it only has to have *one* digital certificate for trading with *all* potential partners - unlike the horrible burden placed on it if separate paper TPAs have to be negotiated with each and every individual trading partner. For some useful background on Heathcare PKIs, please see stuff about the AFEHCT/WEDi Healthcare Internet Security Interoperability Pilot at http://www.afehct.org/security.asp, and PKI in Healthcare at http://www.healthkey.org/library.htm. William J. Kammerer Novannet, LLC. +1 (614) 487-0320
