Re: digital certificates for access to CPP repository
Somehow, during the discussions of SPAM, anti-SPAM, Kennedy's bill, invitations to testing webinars, etc., we must have lost track of Chris Feahr's Registry authentication questions (below). Though this is indeed a big can of worms, fortunately we have folks on board who take special interest in such things - namely, our friends from US NIST. The OASIS ebXML Registry Technical Committee is also looking at these kinds of problems within its Security Services sub-committee. Maybe I can persuade Lisa Carnahan to take our requirements back to the Security Services people. Lisa is both a member of the OASIS ebXML Registry TC and of our group, and she has volunteered to be our Registry expert and co-author our working paper on Discovery of Healthcare CPPs. As an aside, Joe Rosmann has reminded me that there is an ebXML paper - the ebXML Registry Security Proposal - that gives some background on authentication, integrity and confidentiality with respect to the ebXML Registry; it's a little dated and rough, but still available at http://www.ebxml.org/specs/secREG.pdf. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'joe mcverry' [EMAIL PROTECTED]; 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Wednesday, 12 June, 2002 02:05 PM Subject: RE: digital certificates for access to CPP repository Joe, I understand. On the other hand, how else would you authentic an entity attempting to access a CPP reposistory? Furthermore, even assuming authentication, it's not at all clear to me that all entities would want their CPP info to be accessible to all parties accessing such a registry. This is a big can of worms and without any business case and business requirements, I believe that details of this type are much too premature. My concern is about the complexity that is ensuing as a result of these discussions and that I don't believe this (CPP/A, registry, etc.) is at all essential for health care to achieve compliance with HIPAA by the various drop-dead dates. Rachel -Original Message- From: joe mcverry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 9:42 PM To: [EMAIL PROTECTED] Cc: 'WEDi/SNIP ID Routing' Subject: Re: digital certificates for access to CPP repository If authentication is in place then there should be no need to worry about digital certificates for access to CPP repository. - Original Message - From: William J. Kammerer [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, 11 June, 2002 04:18 PM Subject: Re: digital certificates for access to CPP repository In the current version of the OASIS ebXML Registry specification, there are no provisions for confidentiality of Registry content. All content submitted to the Registry may be discovered and read by any client - which means anybody can find out that an entity is accessible via the registry, and where their CPP is located. On the other hand, only authorized submitters who have been authenticated using digital signatures can publish data in the registry. I am assuming that this means there exists a fine-grained mechanism whereby only the owner (or his agent) of information (e.g., the CPP) can submit or change his own information - as opposed to having to submit his information through a central authority for inclusion in the Registry. The CPP owner may have some means of obfuscating his own CPP, or parts thereof - revealing information only to authorized users- since the CPP itself could very well reside on his own server. Of course, I'm making a lot of assumptions. The details have to be ferreted out by the folks responsible for the working paper on Discovery of Healthcare CPPs: Peter Barry, Joe McVerry, and Dick Brooks! I think Joe only volunteered to look into UDDI. That leaves Peter and Dick to be the experts on the ebXML Registry. Maybe I could add Lisa Carnahan to the list, too. Does anyone else want to volunteer? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, 10 June, 2002 06:31 PM Subject: digital certificates for access to CPP repository Dear Group: I would like to know if we have agreement (or could agree) on the following requirements regarding access to the CPP registry/repository data: 1. Allow any party to access the CPP registry, thus obtaining the URL that points to an entity's repository record(s). 2. Require a standard mechanism for entrance to the CPP repository record that somehow looks for a valid digital ID certificate If every CPP repository user was required to have a valid ID certificate somewhere (e.g., the AMA/Verisign deal that was mentioned once) then requiring that certificate as the entry pass to the repository would seem to be a way to keep the riff-raff out. I think we may still need ways
RE: digital certificates for access to CPP repository
Joe, I understand. On the other hand, how else would you authentic an entity attempting to access a CPP reposistory? Furthermore, even assuming authentication, it's not at all clear to me that all entities would want their CPP info to be accessible to all parties accessing such a registry. This is a big can of worms and without any business case and business requirements, I believe that details of this type are much too premature. My concern is about the complexity that is ensuing as a result of these discussions and that I don't believe this (CPP/A, registry, etc.) is at all essential for health care to achieve compliance with HIPAA by the various drop-dead dates. Rachel -Original Message- From: joe mcverry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 9:42 PM To: [EMAIL PROTECTED] Cc: 'WEDi/SNIP ID Routing' Subject: Re: digital certificates for access to CPP repository If authentication is in place then there should be no need to worry about digital certificates for access to CPP repository. Rachel Foerster wrote: Oh Lordy, Lordy! Are we going down a rabbit hole with Alice or what! I understand authentication is part of the CPA spec, but how is this relevant to getting the industry up and running with EDI by the HIPAA compliance dates? Rachel -Original Message- From: joe mcverry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 4:13 PM To: WEDi/SNIP ID Routing Subject: Re: digital certificates for access to CPP repository Authentication has been addressed in several levels. For example a snippet from the ebXML CPA documents reads quote 8.4.13.5 isAuthenticated attribute - The isAuthenticated attribute has the possible values of none, transient, persistent, and persistent-and-transient. If this attribute is set to any value other than none, then the receiver MUST be able to verify the identity of the sender. In general, transient authentication can be implemented using a secure transport protocol like SSL (with or without the use of basic or digest authentication); persistent authentication can be implemented using a digital signature mechanism. Secure transport information is further provided in the TransportSender (see Section 8.4.24) and TransportReceiver (see Section 8.4.32) elements under the Transport element. Persistent authentication information is further provided in the SenderNonRepudiation element under DocExchange/ebXMLSenderBinding (see Section 8.4.42) and the ReceiverNonRepudiation element (under DocExchange/ebXMLReceiverBinding (see Section 8.4.53). The CPA would be inconsistent if isAuthenticated is set to transient or persistent-and- transient, while isSecureTransportRequired is set to false. 8.4.13.6 isAuthorizationRequired attribute The isAuthorizationRequired attribute is a Boolean with possible of values of true and false. If the value is true then it indicates that the delivery channel MUST specify that the sender of the Message is to be authorized before delivery to the application /quote Source: Collaboration-Protocol Profile and Agreement Specification Version 1.11 Author: OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee Date: April 4 2002 URL: http://www.oasis-open.org/committees/ebxml-cppa/documents/working_drafts/ebC PP-1_11.pdf William J. Kammerer wrote: In the current version of the OASIS ebXML Registry specification, there are no provisions for confidentiality of Registry content. All content submitted to the Registry may be discovered and read by any client - which means anybody can find out that an entity is accessible via the registry, and where their CPP is located. On the other hand, only authorized submitters who have been authenticated using digital signatures can publish data in the registry. I am assuming that this means there exists a fine-grained mechanism whereby only the owner (or his agent) of information (e.g., the CPP) can submit or change his own information - as opposed to having to submit his information through a central authority for inclusion in the Registry. The CPP owner may have some means of obfuscating his own CPP, or parts thereof - revealing information only to authorized users- since the CPP itself could very well reside on his own server. Of course, I'm making a lot of assumptions. The details have to be ferreted out by the folks responsible for the working paper on Discovery of Healthcare CPPs: Peter Barry, Joe McVerry, and Dick Brooks! I think Joe only volunteered to look into UDDI. That leaves Peter and Dick to be the experts on the ebXML Registry. Maybe I could add Lisa Carnahan to the list, too. Does anyone else want to volunteer? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, 10 June
Re: digital certificates for access to CPP repository
Chris Rachel, I've been holding back on this message for awhile, and some of my information has already been addressed by Rachel or Joe, but I've kept it in this response anyway. Chris' asks: 1. Allow any party to access the CPP registry, thus obtaining the URL that points to an entity's repository record(s). 2. Require a standard mechanism for entrance to the CPP repository record that somehow looks for a valid digital ID certificate If I've interpreted Joe's response correctly, he has provided the technical basis for how information can be shared with trusted and unknown entities. Not having the opportunity to read all the technical functions of the ebXML work, I'd like to believe they've got much of the functionality figured out to allow an entity the ability to protect their digital assets. But with regards to our efforts, my suggestion would be that anyone requesting access to the Healthcare CPP should be required to be fully registered with the Healthcare CPP. So if you don't provide your information including a valid digital certificate, you don't have access to others. I also think this initial registration should only allow access to Testing requirements or publicly known business requirements and each entity would have the freedom to define what others can access based upon a level of trust. This may be over complicating the situation, but it only makes sense to me that an entity would not release certain information to just anyone. From Joe's response, I would assume this is all possible. Also, by requiring entities to register, they could select whether or not they want active membership to be notified of their entry. If so, a receiving entity could develop the ability to automate the Trading partner agreement process (workflow). Otherwise, new CPP entities could notify each individual business that they are interested in an electronic relationship. The new business should not have to forward a bunch of TPA documents, but simply pull CPP for the information, and then provide documents that can be digitally signed using a trusted digital signature, or printed and then manually signed and returned. And, in response to Rachel's request for a real problem definition document. We all know that most of larger organizations have the resources in place to assess and plan for HIPAA, as demonstrated in the latest HIMSS surveys. The issues arise when the medium to smaller businesses attempt to determine where to start, what to do, and how long it will take. If I remember the HIPAA statistics correctly, there are slightly over 6000 Hospitals in the U.S. and over 80% of institutional claims are now electronic. Which means the institutions have already built the necessary relationships and have established much of the connectivity. Most likely the remaining players are the smaller facilities and the smaller insurance plans that haven't yet automated claim entry, adjudication or payment/posting systems. On the other hand, from the HIPAA statistics there are over 750,000 physicians, and I believe it was only 35% of professional claims (Physician Services, Dental, Optical, etc.) are electronic. These are the little guys... There are also many business associates that have yet to figure out where they fit as well. If the little guys are willing to out source their EDI compliance to a Clearinghouse, this could significantly improve the numbers, but arguably (ClaimsNet and others may disagree) even some of the Clearinghouses don't want to be bombarded by every 1-5 physician practice for EDI services - support costs are simply too high for the 20-150 claims per day they might see, or the physicians are not willing to pay the setup costs and ongoing support/transaction fees. So, once a physician upgrades or buys a HIPAA TC compliant office/admission billing management system, and is ready to hook it up to the EDI world, where does he begin? How long would it take to get all of the plans he participates with to approve his transaction interfaces? Or is the clearinghouse his only hope? Even if every covered entity was able to demonstrate that they can produce or process the HIPAA Transactions and Code Sets, determining how to Route transactions to the appropriate covered entity or business associate for processing will be challenging. So, establishing a standard method for discovering how and where to send EDI documents, what identifiers to use to ensure proper routing, seems to be the issue this group is attempting to resolve. If a Standard Service was available for any registered healthcare organization to lookup the business and technical requirements for conducting electronic data/document interchanges with any other registered healthcare organization, I think that could significantly reduce the barriers for organizations to become connected. Especially if the process can be fully automated such that the applications can discover and determine the Interchange and
Re: digital certificates for access to CPP repository
In the current version of the OASIS ebXML Registry specification, there are no provisions for confidentiality of Registry content. All content submitted to the Registry may be discovered and read by any client - which means anybody can find out that an entity is accessible via the registry, and where their CPP is located. On the other hand, only authorized submitters who have been authenticated using digital signatures can publish data in the registry. I am assuming that this means there exists a fine-grained mechanism whereby only the owner (or his agent) of information (e.g., the CPP) can submit or change his own information - as opposed to having to submit his information through a central authority for inclusion in the Registry. The CPP owner may have some means of obfuscating his own CPP, or parts thereof - revealing information only to authorized users- since the CPP itself could very well reside on his own server. Of course, I'm making a lot of assumptions. The details have to be ferreted out by the folks responsible for the working paper on Discovery of Healthcare CPPs: Peter Barry, Joe McVerry, and Dick Brooks! I think Joe only volunteered to look into UDDI. That leaves Peter and Dick to be the experts on the ebXML Registry. Maybe I could add Lisa Carnahan to the list, too. Does anyone else want to volunteer? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, 10 June, 2002 06:31 PM Subject: digital certificates for access to CPP repository Dear Group: I would like to know if we have agreement (or could agree) on the following requirements regarding access to the CPP registry/repository data: 1. Allow any party to access the CPP registry, thus obtaining the URL that points to an entity's repository record(s). 2. Require a standard mechanism for entrance to the CPP repository record that somehow looks for a valid digital ID certificate If every CPP repository user was required to have a valid ID certificate somewhere (e.g., the AMA/Verisign deal that was mentioned once) then requiring that certificate as the entry pass to the repository would seem to be a way to keep the riff-raff out. I think we may still need ways to individually [further] secure sections of the repository record, but would a dig. certificate be a reasonable way to secure the repository front door? My suggestion would be to include a data element in the repository (perhaps another URL) that pointed to a default access denied message created by the repository record owner. (I guess in the absence of an entity-specific access denied message that provided an alt. means like a cust. service phone #, the user would simply get a page not found error) More questions (assuming that we do want to secure the front door with a certificate): 1. How tough are these to obtain? Could Mr. Hacker apply for one and thereby have the keys to the kingdom? 2. Are there standard protocols (possibly in the ebXML CPP specifications) for implementing this type of auto-authentication when you attempt to access a URL? 3. How many data elements would be necessary in the repository record to handle auto-auth... and what would they be called? Regards, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
